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

[Nikos Mavrogiannopoulos <[e-mail]>]

On Tue, Jun 5, 2012 at 10:39 PM, Adam Langley <[e-mail]> wrote:

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

In the situation you describe, I see two issues:
1. Various TLS extensions never mention whether they should be
implemented in SSL 3.0. I've raised that previously in this ML [0]
with no particular outcome. An alternative way to this issue is to
explicitly allow SSL 3.0 to use elliptic curves.
2. The fallback strategy implemented by the browsers is weaker than
the TLS protocol itself. The TLS protocol protects only if you do a
fallback within the protocol.

and btw why fallback to RSA and not DHE-RSA if forward secrecy is an
issue? There are techniques to bring DHE-RSA efficiency close to
elliptic curves.

[0]. http://www.ietf.org/mail-archive/web/tls/current/msg08509.html

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

What will happen if the attacker makes such a handshake fail? Would
browsers reconnect without this ciphersuite? (I remember there used to
be SSL servers that closed the connection once encountered with a
ciphersuite they didn't understand).

Who will benefit from that?
1. Is that a user that wanted forward secrecy? In that case using
DHE-RSA would mitigate the issue.
2. Is that a user that did not want to use SSL 3.0? Then SSL 3.0
should have been disabled.

regards,
Nikos