[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 [127.0.0.1]) 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-Level:
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [209.85.213.172]) 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 10.50.163.99 with SMTP id yh3mr4358881igb.53.1338928786955; Tue, 05 Jun 2012 13:39:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.163.99 with SMTP id yh3mr4358866igb.53.1338928786788; Tue, 05 Jun 2012 13:39:46 -0700 (PDT)
Received: by 10.231.5.201 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. 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