[TLS] Cipher suite values to indicate TLS capability

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

Return-Path: <agl@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5238521F8512 for <tls@ietfa.amsl.com>; Tue, 5 Jun 2012 13:39:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cMU6aIcbYDsu for <tls@ietfa.amsl.com>; Tue, 5 Jun 2012 13:39:47 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id B2D0C21F87D2 for <tls@ietf.org>; Tue, 5 Jun 2012 13:39:47 -0700 (PDT)
Received: by yenq13 with SMTP id q13so4873246yen.31 for <tls@ietf.org>; Tue, 05 Jun 2012 13:39:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record; bh=dFTN6NVdRQfHUXHtwGNOTcZ+H8psYGsGuXNtTlhrtCU=; b=M0rgEthWpPPBVtdxKZ2M9dBV3cmZ4NmTCLbth0lK1hL7qkW0mVuGsB2/wHMqgdt5GL DsFOe9T9d8ga0nOSCA5BDG/SuUhSDQC7N/Ehh51scQO3F4QEb02OY/2HdauvqnMyNSzm sO14m76KrUue5beMxlg7f/dWceQybRby19OCh2FwzJBqZtz7fHl4lRe8eh3aybDEEXKP xpGNnnQSvieSgbPJX5eEIe2tpZBoibKlw5RsLnkLludy0thFysyiRgtxCs7DMbe6I+3u RSagVjag21rmWhqkYAEZsZ/4RD0cxYea1MGzagDCfyW0H1YMuSWCpH+3XiWvGKzLcDXX jj9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record:x-gm-message-state; bh=dFTN6NVdRQfHUXHtwGNOTcZ+H8psYGsGuXNtTlhrtCU=; b=moeaYWOaeiufHvASCr4dDoVr8pNlcfHwkDyq8O8He1ZQ364USto2OXrhMHV4tiANg2 sspWbBZ4zH0jS4ZtI0knGib7DKHeKM51P7IJtntrIzXS0G8ab1qyjevGdy8MwtXO/eGK OfpAWAnBChzJQzx2LJ7O1JRmK0rJ8ASuaQ9W5bLQAJTQYyfb0fvTFxIXd2JZec/cY4Ob J8wPV11FsT8eWcNg6k/02r+E1dtHxRZY4DLsGvfSkUAc+YV9sJwF7RwFqMbTetmP9i3R gEe9thHGFiq3WAbnOAWfTimhFPO1GTzmUoevwpRTFV97MCFi/BhWgzRlMqVkrrf9PJTE t/HA==
Received: by with SMTP id yh3mr4358881igb.53.1338928786955; Tue, 05 Jun 2012 13:39:46 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id yh3mr4358866igb.53.1338928786788; Tue, 05 Jun 2012 13:39:46 -0700 (PDT)
Received: by with HTTP; Tue, 5 Jun 2012 13:39:46 -0700 (PDT)
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"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQlSdFWIDfNhQHaotoMWKSGxusI1cyRiFXnTkkDJSqPL0dX+0fhAXsr809miMg9sOOVYWk7sR1GyBFxBTM2QPdT6rUkcPBh6rr5TljIhTlBRuSlmheHjepn31+2gUJ+KV25TdWvb
Subject: [TLS] Cipher suite values to indicate TLS capability
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jun 2012 20:39:48 -0000

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