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

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

24.4.2011 8:24, Peter Gutmann kirjoitti:
>> 1. Client sends a ClientHello with elliptic_curves extension specifying its
>> supported extensions
> But the elliptic_curves extension isn't part of the ClientHello.  This is the
> problem, the ClientHello contains a notification-of-intent and then later bits
> and pieces contain the actual suite details.  If any of the later bits and
> pieces don't as expected you have to go back to the ClientHello and try
> another Chinese-menu option, then go back to the later extensions and see
> if... and so on, although in practice everything I've seen so far just aborts
> the handshake if they don't see exactly what they expect.

I don't quite understand this part, I know it is not indicated as MUST 
in the current RFC, but the text quite clearly says:

    The extensions SHOULD be sent along with any ClientHello message that
    proposes ECC cipher suites.

...

    A client that proposes ECC cipher suites in its ClientHello message
    appends these extensions (along with any others), enumerating the
    curves it supports and the point formats it can parse.  Clients
    SHOULD send both the Supported Elliptic Curves Extension and the
    Supported Point Formats Extension.


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. I'm not saying the suggested 
draft is not a good idea, I think it looks pretty good, I'm just saying 
the situation doesn't seem quite as bad as suggested.

I think the reference to Microsoft's SChannel cipher suites was a very 
good one. I wasn't aware they have already chosen to take this approach 
and it's one more argument for defining it officially. However, I'm also 
wondering why ECDHE_RSA is dropped from the draft? Even Microsoft has 
included ECDHE_RSA cipher suites in their list and since almost all 
certificates in use are RSA certificates, it is quite likely that 
ECDHE_RSA cipher suites are the only cipher suites existing TLS servers 
can start to use immediately without applying for a new certificate. 
(one can argue that they could just use RSA key exchange, but that 
doesn't have forward secrecy like ECDHE does)

Also mandating the same curve in ECDSA signature as in ECDH keys could 
be debated, but I think it's quite well justified here. It's also worth 
to note that this draft doesn't require the whole certificate chain is 
signed with ECDSA and certain curve, so for example a certificate 
containing P-256 keys signed with something else would still be valid. I 
think this is good for flexibility, in case the server administrator is 
unable to obtain a ECDSA certificate signed with ECDSA. It's up to the 
client to find out if it's able to determine its validity then.


Juho