Re: [TLS] DSS with other than SHA-1 algorithms

[Peter Gutmann <[e-mail]>]

"=?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?=" <[e-mail]> writes:

>I don't see how this works, because in case of ECC the server is always
>selecting the cipher suite and sending the ServerKeyExchange, and these both
>happen between ServerHello and ServerHelloDone. What did I miss?

Say you (i.e. the server) see, and select,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, as the best suite.  Then later in the
exchange the client says, via an extension, that it wants to do P256, which
isn't really suited for use with SHA384 (unless you go through odd truncation
calisthenics, but then why use a hash with a key size that's too short for
it?), so you have to go back and reprocess the hello to see if there's
something with SHA256 present to match that.  Then you go back and reprocess
the extensions to see whether that's OK.  In the end you may end up falling
back to a non-ECC suite, depending on your heuristics.  Of course no
implementation actually does this, they just fail the handshake unless they
see the exact parameters they want.

In practice it's even worse than that, you can use completely different curves
for the key exchange, to sign the key exchange, and for client auth, and for
hashes it's nearly as bad.  What are you supposed to do if an implementation
uses (say) P192 for the keyex signature but P521 for the keyex itself?  What
security level do you treat this as being?  You can use the unnncessary
flexibility to make a complete mess of things, and from the little testing
I've done almost anything you do that's slightly unusual results in a
handshake failure or dropped connection, and I don't even want to try and see
what happens when you start using the really odd capabilities, non-named
curves and point compression and other oddities.

So at the moment we already have a kind of de facto profile, mostly it seems
to be P256+SHA256 everywhere, with optional P384+SHA384 everywhere, and I
think I got away with P521 once or twice.  The single profile we have for ECC
use with TLS, the Suite B one, already does this, it's 256-throughout (ECC
keys and hashes) or 384-throughout (ECC keys and hashes).

Peter.