Re: [TLS] Cipher suite values to indicate TLS capability
Nikos Mavrogiannopoulos <nmav@gnutls.org> Wed, 06 June 2012 07:12 UTC
Return-Path: <n.mavrogiannopoulos@gmail.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 03FAB11E8094 for <tls@ietfa.amsl.com>; Wed, 6 Jun 2012 00:12:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 CHt6532vIwx7 for <tls@ietfa.amsl.com>; Wed, 6 Jun 2012 00:12:56 -0700 (PDT)
Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E99F11E808C for <tls@ietf.org>; Wed, 6 Jun 2012 00:12:56 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so5567580ghb.31 for <tls@ietf.org>; Wed, 06 Jun 2012 00:12:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=BhyO9HYV1Eu7iaZRNCepb1rmUiSqRtYtCgqMJ1DWXDc=; b=mzAGOUnLNg2RAXldrxY7PSY89hlVsNpGRjR5c9R9yXHEgDT+U6WzGLe0vw6/iEslOz Q2yOtkMZ2boVkSYgvEGnjtV8mT3BuLya1goEiMfKFwRuKMU/8P+Ze3NoVHYtB4dF5n36 AtxUJ09CKmz+sSXI+8XftDVxJ+KWCLCSg31JN9x1nuzFGbgU8AiPShJtJYKm64wYIyn6 4NdQoGgOIGrT1aMP9/h4qyRav+VpE7n3HxDg3prbqns4fm8yVi2Jfm1muRTknFGLLiNP JzGdUDB+ZhDpdynlJ8kRfeVS75G/GocwrvL1fbD6coRHJZ/pVlo0sUGfk5UUfO7w3hN8 8aPg==
MIME-Version: 1.0
Received: by 10.50.160.202 with SMTP id xm10mr5593584igb.10.1338966775513; Wed, 06 Jun 2012 00:12:55 -0700 (PDT)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.231.80.15 with HTTP; Wed, 6 Jun 2012 00:12:55 -0700 (PDT)
In-Reply-To: <CAL9PXLwdQctUub5oPx0tepsfveDo0bNKGBUaUBBFeq4u4D0BbA@mail.gmail.com>
References: <CAL9PXLwdQctUub5oPx0tepsfveDo0bNKGBUaUBBFeq4u4D0BbA@mail.gmail.com>
Date: Wed, 06 Jun 2012 09:12:55 +0200
X-Google-Sender-Auth: T7Bf-OsNRaqCh2JH7W87awbFb5E
Message-ID: <CAJU7zaLqgjfSM_uKPhm0uuaLZMR0JGB8U40S164FjFPqWhxujw@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: Adam Langley <agl@google.com>
Content-Type: text/plain; charset="UTF-8"
Cc: tls@ietf.org
Subject: Re: [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: Wed, 06 Jun 2012 07:12:57 -0000
On Tue, Jun 5, 2012 at 10:39 PM, Adam Langley <agl@google.com> 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
- 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