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:

>So every client sending a ClientHello SHOULD append the Supported Elliptic
>Curves extension in ClientHello itself and therefore the selected curve
>should be clear immediately after receiving the complete ServerHello
>including ServerKeyExchange.

Hmm, I'll try and explain this again... consider how the parts of the Client
Hello are processed.  For standard suites the server iterates through a list
of suites and selects the most cromulent one.  In my case I just have a list
of suite IDs and parameters sorted in order of preference and select the
lowest-ranked suite I find, I assume most implementations do something more or
less similar.

For the Chinese-menu suites, the server finds a Chinese menu selector and then
has to skip the remaining suites and other parts of the hello and process the
extensions to see whether what's in there matches up with that the Chinese-
menu selector requested.  For example if the Chinese menu said
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 but the supported-curves says P256
then you have to either hope the other side does the special-case X9.62
handling for hash truncation and gets it right (and I've never been able to
find anything that does this to test mine against so who knows whether
anything does do it, and does get it right), or not take the gamble and go
back to the cipher suites and look for another Chinese-menu option, and then
skip the rest of the hello and process the extension again to see if things
work out now, and if that doesn't work either then go back ...

In practice, with the servers I tried, it was hard enough just trying to
figure out which basic combinations they supported (the usual response was a
dropped connection or aborted handshake, so I had to use trial-and-error
probing, and with some servers I never did figure out how to do more than one
or two basic combinations), and I never got to the point of being able to
interop test any of the more exotic combinations like e.g. hash truncation.

So the sole purpose of this RFC is to try and indentify the common
combinations of parameters that everyone seems to implement anyway and list
them as conventional cipher suites, with no further parameterisation required.
The intent is to try and document what everyone's doing already anyway.

Peter.