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

[Geoffrey Keating <[e-mail]>]

Adam Langley <[e-mail]> writes:

> (I'm floating this idea before implementing it.)
> 
> All major HTTPS clients (and possibly other TLS clients too) implement
> fallback in order to workaround buggy networks and buggy servers. If a
> handshake fails with any one of a number of spoofable errors, the
> client will retry with more conservative options enabled. Eventually
> the client will retry the connection with vanilla SSLv3.
> 
> There is no indication that the world is going to improve to the point
> where we can remove this fallback any time soon. About 1% of
> connections still need to do it.
> 
> However, with the downgrade to SSLv3 we loose an important security
> feature: ECDHE. As SSLv3 doesn't support ECDHE, an attacker can cause
> the key-agreement algorithm to switch from ECDHE-RSA to RSA (this
> affects Google at least). On the server side, we're not going to
> switch on multiplicative DH at a strength similar to P-256 because of
> the DoS impact so clients will loose forward security. Also, with a
> plain RSA ciphersuite, it's possible for an attacker with the server's
> private key to decrypt the pre-master secret and assume control of a
> TLS connection. This means that the attacker will be authenticated
> with any client-certificate used, something that isn't possible with
> forward secure ciphersuites.

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

> So I'd like to introduce TLS_CAPABLE_SCSV (0x00fe) in SSLv3
> handshakes. TLS_EMPTY_RENEGOTIATION_INFO_SCSV has shown that we can
> deploy new ciphersuites for SSLv3 and the semantics of
> TLS_CAPABLE_SCSV would be that servers would reject any SSLv3
> handshakes that included this ciphersuite with a fatal error. (Thus
> TLS_CAPABLE_SCSV would only be included when the handshake was the
> result of a fallback.)

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.

So, I don't think this is a good candidate for standardization.  You'd
need to come up with a 'preferred' client hello, and then have the
cipher suite value mean very specifically that the preferred client
hello should have been accepted...