Subject: [TLS] EllipticCurveList is not expressive enough

From: "Brian Smith" <[email-masked]>
Date: Fri, 23 Jul 2010 12:14:05 -0500

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

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 24 Jul 2010 06:01:10 +1200

"Brian Smith" <[email-masked]> writes:

>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.

Given that pretty much the only thing that's ever likely to use this is
something doing Suite B, why not just make it a simple flag, { suite-B-medium,
suite-B-strong, suite-B-RFU }?  That makes it much easier than even further
complicating an already pretty awkward negotiation process when ECC is
involved (and by "complicating" I mean "providing implementors with lots of
scope for creating a non-interoperable mess").  It also goes with the spirit
of working with complete suites, being able to negotiate everything in bits
and pieces in order to make a mess is more an IPsec thing.

In fact you don't even need the choice-of-suite flag, all you need to do is
tell the other side to follow Suite B semantics, so an empty extension is
enough.  The other side can then decide, based on whether you specify p256 or
p384, what other things need to be switched on.

Given that the spec more or less outlaws any non-Suite-B stuff, my guess is
that you'd either be operating in Suite-B-only mode or generic mode, in which
case you wouldn't even need that.

>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.

You wanna feed at the USG funding trough, you gotta jump through their hoops
:-).

Peter.

---

From: Kyle Hamilton <[email-masked]>
Date: Mon, 26 Jul 2010 03:17:25 -0700

> public key MUST use the P-384 curve and be signed with the P-384 curve."
[...]
> at the 128-bit security level, but the Suite B profile doesn't allow that.
The NSA does not answer questions.  The NSA simply dictates what reality
shall be.  Yes, the Suite B profile really does need to be that strict,
because the NSA says that it needs to be that strict.  The Suite B
profile is the set of encryption and authentication schemes that the NSA
has deemed acceptable to encrypt classified data.

-Kyle H

---

From: Dean Anderson <[email-masked]>
Date: Wed, 28 Jul 2010 21:54:50 -0400 (EDT)

:-)

Wasn't it the NSA that told MS to compromise Windows security a while
back? (unintentionally, of course--they just didn't think it all the way
through)  I return you to your regular security-bashing.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 256 5494