[TLS] Cipher suite values to indicate TLS capability

Adam Langley <agl@google.com> Tue, 05 June 2012 20:39 UTC

MIME-Version: 1.0
Date: Tue, 05 Jun 2012 16:39:46 -0400
Message-ID: <CAL9PXLwdQctUub5oPx0tepsfveDo0bNKGBUaUBBFeq4u4D0BbA@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: tls@ietf.org
Content-Type: text/plain; charset="UTF-8"
Subject: [TLS] Cipher suite values to indicate TLS capability
Precedence: list

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

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

That begs the question of whether we should introduce
TLS_1_1_CAPABLE_SCSV and TLS_1_2_CAPABLE_SCSV. At the moment we don't
have any critical security benefits in TLS 1.1 or 1.2 that an attacker
could deny us by forcing a fallback, therefore I don't see a pressing
need for them at the moment.

If there aren't any solid objections, I'll write up a draft.


Cheers

AGL

Re: [TLS] Cipher suite values to indicate TLS cap… Geoffrey Keating
[TLS] Cipher suite values to indicate TLS capabil… Adam Langley
Re: [TLS] Cipher suite values to indicate TLS cap… Adam Langley
Re: [TLS] Cipher suite values to indicate TLS cap… Geoffrey Keating
Re: [TLS] Cipher suite values to indicate TLS cap… Adam Langley
Re: [TLS] Cipher suite values to indicate TLS cap… Adam Langley
Re: [TLS] Cipher suite values to indicate TLS cap… Geoffrey Keating
Re: [TLS] Cipher suite values to indicate TLS cap… Adam Langley
Re: [TLS] Cipher suite values to indicate TLS cap… Chris Richardson
Re: [TLS] Cipher suite values to indicate TLS cap… Wan-Teh Chang
Re: [TLS] Cipher suite values to indicate TLS cap… Yoav Nir
Re: [TLS] Cipher suite values to indicate TLS cap… Yoav Nir
Re: [TLS] Cipher suite values to indicate TLS cap… Nikos Mavrogiannopoulos
Re: [TLS] Cipher suite values to indicate TLS cap… Geoffrey Keating
Re: [TLS] Cipher suite values to indicate TLS cap… Chris Richardson
Re: [TLS] Cipher suite values to indicate TLS cap… Tom Ritter
Re: [TLS] Cipher suite values to indicate TLS cap… Nikos Mavrogiannopoulos
Re: [TLS] Cipher suite values to indicate TLS cap… Adam Langley
Re: [TLS] Cipher suite values to indicate TLS cap… Nikos Mavrogiannopoulos
Re: [TLS] Cipher suite values to indicate TLS cap… Adam Langley
Re: [TLS] Cipher suite values to indicate TLS cap… Martin Rex