Re: [TLS] One approach to rollback protection

Martin Rex <mrex@sap.com> Tue, 27 September 2011 01:33 UTC

Return-Path: <mrex@sap.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 0826F21F8EA3 for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 18:33:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.057
X-Spam-Level:
X-Spam-Status: No, score=-10.057 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 18OCMinGIEQv for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 18:33:16 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4711821F8EA1 for <tls@ietf.org>; Mon, 26 Sep 2011 18:33:16 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8R1Zq40007511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 03:35:57 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201109270135.p8R1Zq7h016386@fs4113.wdf.sap.corp>
To: ekr@rtfm.com (Eric Rescorla)
Date: Tue, 27 Sep 2011 03:35:52 +0200 (MEST)
In-Reply-To: <CABcZeBMx=cmXoL9oM5RPxZPyB9OmEWqDfGxo0dDJmG+oAJgvvw@mail.gmail.com> from "Eric Rescorla" at Sep 26, 11 06:19:07 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] One approach to rollback protection
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Sep 2011 01:33:17 -0000

Eric Rescorla wrote:
> > 
> > > If the SCSV value is present and is not equal to
> > > ClientHello.client_version, then the server MUST terminate
> > > the handshake with a fatal "handshake_failure" alert.
> >
> > This doesn't really make the deployment of new TLS versions that much
> > easier. The client would still have to try 1.2, 1.1, 1.0 etc. What
> > would be helpful is if the server, seeing a TLS 1.2 SCSV, treated the
> > client as if it has advertised 1.2.
> 
> That's certainly a possibility, but now we're actually substituting
> the negotiation mechanism with one based on smuggling it in ciphersuites,
> which is pretty gross.

Now I'm somewhat puzzled.

Was your motivation to propose this only to ensure that a TLSv1.0,
SSLv3 or SSL Version 2 CLIENT-HELLO results in a fatal handshake failure
when both peers support higher than TLSv1.0?

I'm strongly opposed to that idea.

What I'm looking for is a protocol enhancements that will **IMPROVE**
TLS interop by having more TLS handshakes succeed.


>
> Moreover, unless I'm missing something, this leaves the client unable to offer
> extensions (since they often cause breakage as well) unless it has fallback,
> at which point why not use fallback for version logic as well?

No problem, TLSv1.1 and TLSv1.2 work just fine without extensions.
And if that is really an issue, an alternative would be to perform
a renegotiation directly after the handshake succeeded -- with the
added bonus that it incurs no handshake failure -- meaning that
it could be performed entirely within TLS and without involvement
of the calling application.

A handshake failure is a significant problem, since it always requires
the involvement of the application and a new network connection.


-Martin