[TLS] EllipticCurveList is not expressive enough

["Brian Smith" <[e-mail]>]

1. The NSA suite B profile contains the following requirements: "For cipher
suites at the 128-bit security level, secp256r1 MUST be used.  For cipher
suites at the 192-bit security level, secp384r1 MUST be used." and "For
certificates used at the 128-bit security level, the subject public key MUST
use the P-256 curve and be signed with either the P-384 curve or the P-256
curve.  For certificates used at the 192-bit security level, the subject
public key MUST use the P-384 curve and be signed with the P-384 curve."

2. Some crypto libraries, such as Microsoft's CNG, provide (sysadmin)
options for enabling/disabling ciphersuite/elliptic curve combinations [1],
instead of enabling/disabling cipher suites and elliptic curves
orthogonally. For example, for you can enable
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 with the P-256 curve and disable it
with secp384r1.

A TLS client can use the EllipticCurveList extension to tell the server that
it prefers secp384r1 over secp256r1 or secp256r1 or secp384r1, but it cannot
relay the above restrictions. As a result, the server can choose a curve and
a cipher suite that seem acceptable based on the information in the client
hello, but which the client would have to reject (e.g.
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 with the secp384r1 curve, which a
Suite B client would have to reject).

This makes implementing a robust client quite complicated, as it has to be
prepared to do attempt and abort handshakes several times, each with a
different CipherSuites/EllipticCurveLists combination. And, doing so results
either horrible performance (having to go through the full handshake before
aborting the connection, potentially several times) or susceptibility to
rollback attacks (if the handshake is aborted right after the ServerHello).

Consequently, I think it would be very useful to have a different extension
that allowed the client to spell out its exact requirements: For
ciphersuites <C>, I accept curves <K> for ECDH, curves <E> for the ECDSA
signature, and curves <I> for certificate signatures.

Also, does the Suite B profile really need to be that strict? As far as I
can tell, it should be acceptable (if wasteful) to use the secp384r1 curves
at the 128-bit security level, but the Suite B profile doesn't allow that.

[1] http://msdn.microsoft.com/en-us/library/aa374757(VS.85).aspx

Regards,
Brian