Four ECDSA P256 CSPs are available in Windows. Which one should I use?

Question

According to Azure support case #116120515025419, the public datacenter only supports the following

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

Since my goal is to use ECC with Perfect Forward Secrecy, I think these are my best options.

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256

The cheapest EV cert I can locate is at Namecheap/Comodo, and they support the following curves:

 prime256r1, secp256t1, secp384r1, secp521r1.

I am using this guide to generate my certificate, but I'm not sure of which of the following to choose from

ECDSA_P256 Microsoft Software Key Storage Provider
ECDSA_secP256r1 Microsoft Key Storage provider
ECDSA_secP256k1 Microsoft Key Storage provider
ECDSA_nistP256, Microsoft Key Storage provider

Rationale for wanting ECDSA 256

My choice to use the P256 cert will allow developers to use CBC in addition to GCM. I could choose a higher bit length, but the more secure ECDSA CSPs don't support CBC. Is it wise of me to support CBC?

In case it matters, my target clients are mobile apps, browsers, and IoT devices.

Question

• What is the difference between the curves available in Windows, and which is most appropriate for my use case? (why?)

• If I do have a choice, which of the curves are least error prone in 3rd party implementations?

  

Answer 1

In a cipher suite like TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, there are two involved curves:

• One is used for the ECDHE part: a Diffie-Hellman key exchanged is used between client and server, over a given curve.
• The other is for the ECDSA signature computed by the server: the server signs its ServerKeyExchange message. ECDSA is a signature algorithm that uses computations on an elliptic curve.

There is no requirement that both curves be the same; they are mostly unrelated and live in different worlds. On a conceptual level, the one used for ECDHE is more important, because it must ensure security for the lifetime of the data which will be exchanged over the wire (i.e. if the data is still important ten years from now, then the curve must still be robust ten years from now); the one used in the signature is only for now, and it does not really matter if it gets broken tomorrow.

Note that forward secrecy is all about the key exchange, i.e. the ECDHE part. This is the same idea: security of the signature system matters only for now. Thus, you could perfectly have ECC-powered forward secrecy with a TLS_ECDHE_RSA_* cipher suite, i.e. with an RSA key in the certificate.

Normally, the CSP choice (technically, "CNG key storage provider") is about the type of the private key that will indeed be stored, i.e. corresponding to the certificate and the ECDSA (or RSA) signature. The curve for ECDHE is chosen independently(*), between the client and server, with secrets which are kept in RAM only (and therefore never stored, which is the point of forward secrecy).

That being said, the one curve that is supported everywhere is NIST's curve P-256, also known as "secp256r1" or "prime256r1" (not to be confused with "secp256k1", which is a distinct curve). The NIST curve P-384 also has a fair share of widespread support, although maybe not as much as P-256. Also, P-384 implies a bit more computational work (about three times as much), which does not matter in practice except if some constrained embedded systems are involved (not smartphones; really small systems). An additional point is that P-256 already ensures more than adequate security, even with regards to technological improvements: as far as we know it, if a P-256 ECDHE key exchange ever gets broken, then it will be through use of an as yet mythical quantum computer, and if such a beast is ever built, then it will mince through P-384 with almost as much ease. In that sense, there is no security advantage of using P-384 instead of P-256.

Summary: for maximum interoperability, use P-256. Client and server SSL implementations may still decide to use another curve for the ECDHE part; unless specific guidance is applied, that other curve will usually be P-256 as well, or (depending on involved implementations) Curve25519, which is also a nice choice for security.

---

^{(*) Mostly. Some OpenSSL versions will try to match the ECDHE curve size with the curve used in ECDSA, which may or may not make sense since they relate to different operations with different security characteristics, especially with regards to future technological improvements.}

Answer 2

If possible, none of them. See the last table on this page, choosing Safe Curves: https://safecurves.cr.yp.to/index.html SSL Labs, Best advice: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices

Unsafe Curves:

• P224 P256, P384, -> (unsafe) P521? -> probably unsafe but not listed above.

The only perfectly secure curves are:

• Curve1174
• Curve25519 (the only secure curve in windows that I am aware of, RFC draft-ietf-tls-curve25519, added support in Windows 10, version 1607 and Windows Server 2016)
• Curve41417 formerly named Curve3617
• Curve383187 authors subsequently recommended switching to M-383
• M-221 formerly named Curve2213
• M-383
• M-511 formerly named Curve511187
• E-222
• E-382
• E-521
• Ed448-Goldilocks

My Recommendations:

• ECC curve order "curve25519" ONLY [to prevent 0day downplay attacks], or "curve25519" ALWAYS over "NIST" for compatibility only.
• ECDHE_ECDSA over ECDHE_RSA over DHE_RSA over RSA
• SHA 256 over 384, drop P521 (Unless for top secret. For speed as recommended by SSL Labs.)
• GCM over CBC GCM128 over GCM256 (Unless for top secret. For speed, as recommended by ssl labs.)
• 128-bit CBC over 256-bit CBC (Unless for top secret. For speed, as recommended by ssl labs.)
• SHA-2 over SHA-1 (disable sha on schannel, use only sha256,384,512)

Copy and paste into group policy "Ecc Curve Order"

Curve25519

With this config, No P curve ciphers necessary P=Nist; ECDHE/ECDSA=ECC! Let ECC curve order group policy determine "curve25519"

Perfect forward secrecy only:

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Copy/Paste into Group Policy SSL Cipher Suite Order:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Wireshark:

With nist P curves enabled & prioritized: sls.update.microsoft.com.nsatc.net offered: TLS_ECDHE_RSA_WITH_AES128_GCM_SHA256 named curve: secp256r1 (0x0017) (unsafe NIST/NSA curve, insecure)

fe2.update.microsoft.com.nsatc.net offered TLS_ECDHE_RSA_WITH_AES128_GCM_SHA384 secp256r1, (unsafe NIST/NSA curve, insecure)

With x25519 curve ONLY, enabled: fe2.update.microsoft.com.nsatc.net offered TLS_ECDHE_RSA_WITH_AES128_GCM_SHA384 named curve: x25519 (SAFE)

Schannel = Windows Update, CryptoAPI, IIS (possibly others)