Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv
mrex@sap.com (Martin Rex) Tue, 28 January 2014 03:31 UTC
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC151A039B for <tls@ietfa.amsl.com>; Mon, 27 Jan 2014 19:31:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDGmR-JWb0-h for <tls@ietfa.amsl.com>; Mon, 27 Jan 2014 19:31:46 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 956801A017F for <tls@ietf.org>; Mon, 27 Jan 2014 19:31:46 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s0S3VgJZ019971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Jan 2014 04:31:42 +0100 (MET)
In-Reply-To: <CAL9PXLzGTm-3Ciyg4trja1zYEmOOJ-FTd5zfSTOg95ukpadYPw@mail.gmail.com>
To: Adam Langley <agl@google.com>
Date: Tue, 28 Jan 2014 04:31:41 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140128033141.EEEDE1ABC9@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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, 28 Jan 2014 03:31:49 -0000
Adam Langley wrote: > Martin Rex <mrex@sap.com> wrote: >> A modified extension that allows the server to continue the handshake >> with a TLSv1.2 ServerHello, could be processed transparently within >> the TLS client implementation and provide immediate benefits to TLS clients >> that do not have any application-level reconnect fallback. > > The ServerHello could not contain options that the ClientHello didn't > offer. For example, AES-GCM or even ECDHE (if the client fell back to > SSLv3). Thus an attacker could still choose important features of the > connection. You really do not need to curtail your imagination and creativity so badly. If you have an urge to resend a ClientHello with TLS extensions, how about extending this proposal to allow the client to do this within the handshake rather then dropping the connection like a hot potato and expecting the application to clean up the resulting mess with an app-supplied reconnect fallback facility? The negotiation could work like this: Client is performing a fallback and stripping information from ClientHello (such as TLS extensions or certain cipher suites) that the client would prefer to use if availabe and marks that omission with an SCSV. Server checks the ClientHello, recognizes the SCSV and if the server supports features beyond those currently present in ClientHello _and_ features which would be preferable _to_the_server_ (such as ECC cipher, AES-GCM cipher suites, TLS signature extension), then the server could return ServerHello with ServerHello.cipher_suite=SCSV and ServerHello.server_version set to the highest TLS version supported by the server directly followed by ServerHelloDone, and upon receiving this, the client would simply restart the Handshake with a new ClientHello handshake message that contains all the previously omitted stuff. In a number of situations, the server may simply want to continue the handshake, when the server does not support any features beyond what is offered in that fallback ClientHello, or when the choices present in the fallback ClientHello meet the preferences configured by the server administrator. i.e. when the server admin has configured to prefer TLS_RSA_WITH_AES_128_CBC_SHA, this cipher suite is present in the fallback ClientHello and the server has only a single cipher suite, then it wouldn't matter when ClientHello.client_version is only TLSv1.1 or when there are no TLS extensions in ClientHello, and no need to suggest resending his ClientHello to the client. i.e. the regular full TLS handshake: http://tools.ietf.org/html/rfc5246#page-36 Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data Figure 1. Message flow for a full handshake the fall-forward full TLS handshake: Client Server minimal ClientHello w/SCSV --------> ServerHello w/SCSV <-------- ServerHelloDone ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data Figure 1. Message flow for a full handshake -Martin
- [TLS] Call for acceptance of draft-moeller-tls-do… Eric Rescorla
- Re: [TLS] Call for acceptance of draft-moeller-tl… Ben Laurie
- Re: [TLS] Call for acceptance of draft-moeller-tl… Adam Langley
- Re: [TLS] Call for acceptance of draft-moeller-tl… Kurt Roeckx
- Re: [TLS] Call for acceptance of draft-moeller-tl… Adam Langley
- Re: [TLS] Call for acceptance of draft-moeller-tl… Rob Stradling
- Re: [TLS] Call for acceptance of draft-moeller-tl… Adam Langley
- Re: [TLS] Call for acceptance of draft-moeller-tl… Rob Stradling
- Re: [TLS] Call for acceptance of draft-moeller-tl… Adam Langley
- Re: [TLS] Call for acceptance of draft-moeller-tl… Michael D'Errico
- Re: [TLS] Call for acceptance of draft-moeller-tl… Martin Thomson
- Re: [TLS] Call for acceptance of draft-moeller-tl… Bodo Moeller
- Re: [TLS] Call for acceptance of draft-moeller-tl… Martin Rex
- Re: [TLS] Call for acceptance of draft-moeller-tl… Ben Laurie
- Re: [TLS] Call for acceptance of draft-moeller-tl… Kurt Roeckx
- Re: [TLS] Call for acceptance of draft-moeller-tl… Martin Rex
- Re: [TLS] Call for acceptance of draft-moeller-tl… Daniel Kahn Gillmor
- Re: [TLS] Call for acceptance of draft-moeller-tl… Salz, Rich
- Re: [TLS] Call for acceptance of draft-moeller-tl… Geoffrey Keating
- Re: [TLS] Call for acceptance of draft-moeller-tl… Martin Rex
- Re: [TLS] Call for acceptance of draft-moeller-tl… Martin Rex
- Re: [TLS] Call for acceptance of draft-moeller-tl… Watson Ladd
- Re: [TLS] Call for acceptance of draft-moeller-tl… Martin Rex
- Re: [TLS] Call for acceptance of draft-moeller-tl… Bodo Moeller
- Re: [TLS] Call for acceptance of draft-moeller-tl… Yoav Nir
- Re: [TLS] Call for acceptance of draft-moeller-tl… Daniel Kahn Gillmor
- Re: [TLS] Call for acceptance of draft-moeller-tl… Watson Ladd
- Re: [TLS] Call for acceptance of draft-moeller-tl… Bill Frantz
- Re: [TLS] Call for acceptance of draft-moeller-tl… Yoav Nir
- Re: [TLS] Call for acceptance of draft-moeller-tl… Watson Ladd
- Re: [TLS] Call for acceptance of draft-moeller-tl… Yngve N. Pettesen
- Re: [TLS] Call for acceptance of draft-moeller-tl… Bodo Moeller
- Re: [TLS] Call for acceptance of draft-moeller-tl… Bodo Moeller
- Re: [TLS] Call for acceptance of draft-moeller-tl… Martin Rex
- Re: [TLS] Call for acceptance of draft-moeller-tl… Martin Rex
- Re: [TLS] Call for acceptance of draft-moeller-tl… Michael D'Errico
- Re: [TLS] Call for acceptance of draft-moeller-tl… Michael D'Errico
- Re: [TLS] Call for acceptance of draft-moeller-tl… Adam Langley
- Re: [TLS] Call for acceptance of draft-moeller-tl… Bodo Moeller
- Re: [TLS] Call for acceptance of draft-moeller-tl… Martin Rex
- Re: [TLS] Call for acceptance of draft-moeller-tl… Adam Langley
- Re: [TLS] Call for acceptance of draft-moeller-tl… Andrei Popov
- Re: [TLS] Call for acceptance of draft-moeller-tl… Andrei Popov
- Re: [TLS] Call for acceptance of draft-moeller-tl… Adam Langley
- Re: [TLS] Call for acceptance of draft-moeller-tl… Martin Rex
- Re: [TLS] Call for acceptance of draft-moeller-tl… Watson Ladd
- Re: [TLS] Call for acceptance of draft-moeller-tl… Bodo Moeller
- Re: [TLS] Call for acceptance of draft-moeller-tl… Bodo Moeller
- Re: [TLS] Call for acceptance of draft-moeller-tl… t.petch
- Re: [TLS] Call for acceptance of draft-moeller-tl… Andrei Popov
- Re: [TLS] Call for acceptance of draft-moeller-tl… Yoav Nir
- Re: [TLS] Call for acceptance of draft-moeller-tl… Andrei Popov
- Re: [TLS] Call for acceptance of draft-moeller-tl… Adam Langley
- Re: [TLS] Call for acceptance of draft-moeller-tl… Watson Ladd
- Re: [TLS] Call for acceptance of draft-moeller-tl… Adam Langley
- Re: [TLS] Call for acceptance of draft-moeller-tl… Martin Rex
- Re: [TLS] Call for acceptance of draft-moeller-tl… Joseph Salowey (jsalowey)
- Re: [TLS] Call for acceptance of draft-moeller-tl… Russ Housley
- Re: [TLS] Call for acceptance of draft-moeller-tl… Marsh Ray
- Re: [TLS] Call for acceptance of draft-moeller-tl… Eric Rescorla
- Re: [TLS] Call for acceptance of draft-moeller-tl… Bodo Möller
- Re: [TLS] Call for acceptance of draft-moeller-tl… Yngve N. Pettersen