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

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

4.5.2011 11:56, Peter Gutmann kirjoitti:
>> 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.
> That's quite possible.  At the moment both TLS-ECC and TLS 1.2 deployment is
> so vanishingly small that we have little data to go on, and as an implementer
> you really can't see how problematic things get until you do implement and
> deploy something.  One of the reasons for getting the draft out there is to
> try and both point out, and then address the problem before it becomes a real
> issue.

I think the deployment is very small on the server side, but I would say 
it is quite common on the client side. I know at least Firefox has had 
ECC cipher suites enabled by default for quite a long time (3 years or 
so), and I think that attributes to somewhere close to one third of all 
browsers globally. (according to Mozilla more than 350 million users) 
Calling TLS-ECC deployment vanishingly small is a bit of an 
understatement, don't you think? Should at least carefully consider what 
implications the draft has on interoperability with existing 
implementations, especially if the handshake methods are made mutually 
exclusive.

>> 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.
> Hmm, it should already say that:
>
>        ECDSA signature in Server Key Exchange message: P256 or P384 curve
>        as for ECDH with uncompressed points and SHA1, SHA256 or SHA384 as
>        indicated in the suite name.
>
> And for client auth:
>
>        Client authentication in Certificate Request/Certificate Verify
>        messages: SHA1, SHA256, or SHA384 as indicated in the suite name.
>
> In other words "if you're using SHA256 at location X then you should use it
> at location Y as well" (I can't imagine why you'd want to use, say SHA-1 at
> point X but then SHA256 at point Y, and if anyone really does want this they
> can still do it using the existing Chinese-menu option).

That's exactly the parts of the draft I am referring to. This should be 
combined with the RFC 5246 text:

    If the client does not send the signature_algorithms extension, the
    server MUST do the following:
...
    -  If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
       ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.


Your draft does not mandate sending the signature_algorithms extension, 
but at the same time it does say one should use the SHA256 or SHA386 for 
signatures. Does it override the above clause of TLS 1.2 or does it 
implicate signature_algorithms have to be always sent in case any of 
those cipher suites are to be offered?

> I used the term "Chinese menu" because it's common usage in the US for a mix-
> and-match selection of items, the "one from column A, one from column B"
> selection, and figured using "table d'hote" and "a la carte" might be going a
> bit too far :-).  I'll add a rationale section that discusses the naming (see
> e.g.
> http://www.barrypopik.com/index.php/new_york_city/entry/one_from_column_a_one_from_column_b_chinese_menu_ordering/,
> from a quick Google search, perhaps it's a US-only colloquialism), and also
> more on why there's a problem and why it's a good idea to address it fairly
> soon.

That explains it much better, I tried to google it before but didn't 
really get any sensible results. Looks like searching for "chinese menu 
column" gives more hits, although I wonder how common knowledge it is, 
because most search results seem to be explaining it to readers even 
though they are not technical specifications. But I can confirm at least 
it is not the common way to order food in China.

If we go into slight nitpicking, in Chinese menu the choice from column 
A doesn't affect the choice from column B and the two choices are 
independent. In case of TLS and ECC cipher suites, the choice from 
column A enables making the choice from column B making them mutually 
dependent. I just don't like the term very much, I think referring to 
the two options as simplified ECC parameter selection and extension 
based parameter selection or something similar should suffice. But I can 
wait for the rationale section, I think it's a good idea to add.


Juho