Re: [TLS] EllipticCurveList is not expressive enough

[Peter Gutmann <[e-mail]>]

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

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

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.