Re: [TLS] Cipher suite values to indicate TLS capability

[Adam Langley <[e-mail]>]

On Tue, Jun 5, 2012 at 7:16 PM, Geoffrey Keating <[e-mail]> wrote:
> Could you simply send the ECDHE values anyway?  If the remote end
> accepts them, you can reasonably be sure you're under a downgrade
> attack (but see below).

We would need to send both the ECDHE ciphersuites and the extensions
outlining the acceptable curves and point formats. Adding all that
would reasonably cause SSLv3-only servers to reject the ClientHello.

> One problem with this proposal is that in practice it isn't really
> indicating 'TLS 1.0 capable'.  A system might actually support TLS
> 1.0, but not extensions, or it might have trouble parsing the
> particular EC extensions you sent, or some other extension, or it
> might not like the negotiated cipher suite, or the total number of
> proposed cipher suites, or the compression algorithm.  Or it could
> have mysteriously failed (once) for reasons unconnected to the TLS
> negotiation.

Well, all of those save the last are failures to implement TLS
correctly, so then it's not TLS capable :)

(As for transient network errors: these happen but fallback isn't
intended to work around them. Whatever reconnection logic we might
have is orthogonal to this and would be common between HTTP and HTTPS
connections. We don't actually do fallback from TLS to SSLv3 for TCP
level errors in Chrome.)

Obviously this is a sacrifice of elegance on the alter of practical
need. What the SCSV effectively says is that the server implements TLS
to a level that was common at the time that servers started to be
patched with SCSV support. That isn't perfect, or even good, but it is
still very useful.


Cheers

AGL