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

[Juho Vähä-Herttua <[e-mail]>]

29.4.2011 15:10, Peter Gutmann kirjoitti:
> 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.

Thank you for taking the time to explain it a bit more thoroughly. And 
sorry for asking so many questions, but I want to understand the 
motivation behind this well and on the mailing list it will at least be 
documented for future references.

> 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

Everything clear so far.

> 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

Actually, I tried to look through RFC 4492 (ECC), RFC 5246 (TLS 1.2) and 
RFC 5289, but I didn't find a requirement of using SHA-384 for 
signatures for that cipher suite. So in this case the server could 
choose SHA-256 (in case it can be found from signature_algorithms 
extension) and use that for signature hashing, but use SHA-384 for the 
PRF and therefore perform no hash truncation. It would be silly to use 
two different hashes, but that is how I would probably solve it to 
maintain compatibility. I think it's a general problem with both TLS 1.2 
and ECC specifications, that they're both trying to be flexible and 
extensible up to the point that finding out the actual details becomes 
tedious work and it's more likely for many implementations to "get it 
wrong". I suppose that's exactly the thing you're trying to fix with the 
draft...

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

I think this what makes this worse is that existing TLS 1.0/1.1 
implementations haven't necessarily prepared well for such complicated 
cipher suite selection ECC and TLS 1.2 introduce and that makes the 
transition a bit difficult.

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

Dropping the connection or aborting the handshake is clearly wrong, but 
again as just noted, selecting a cipher suite used to be a simple thing 
and now it's suddenly quite hard. Abortion in that case is an 
understandable solution.

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

Should it be added to the draft that for example implementations using 
mentioned SHA-256 cipher suites must also send signature_algorithms 
extension with corresponding hash and ECDSA pair? Right now it only 
points out the used hash functions, but TLS 1.2 specification quite 
clearly says that one should default to the {sha1,ecdsa} combination if 
no extension is sent. I think this draft doesn't make it clear enough if 
it overrides that requirement or not.

Also, the term "Chinese-menu" is a word I haven't seen in any existing 
TLS related RFC, even though it is very widely used in your draft and 
related discussion. I think it would make sense to at least define the 
meaning of the word a bit more clearly if it is going to be used, but it 
might be worth changing it to something completely different. I for one 
have lived in China for some years and have always managed to agree on 
the menu and the details, so I believe at least the Chinese people might 
find it puzzling. Not to mention someone might even consider it offending...


Juho