Re: [TLS] One approach to rollback protection

Martin Rex <mrex@sap.com> Tue, 27 September 2011 01:19 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 515851F0C47 for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 18:19:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.056
X-Spam-Level:
X-Spam-Status: No, score=-10.056 tagged_above=-999 required=5 tests=[AWL=0.193, 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 pZkr5Kz4wn5l for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 18:19:43 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1FB21F8E21 for <tls@ietf.org>; Mon, 26 Sep 2011 18:19:43 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8R1MOXt020697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 03:22:24 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201109270122.p8R1MOao015930@fs4113.wdf.sap.corp>
To: agl@google.com (Adam Langley)
Date: Tue, 27 Sep 2011 03:22:24 +0200 (MEST)
In-Reply-To: <CAL9PXLybu+RTnHKSw52Crq7Pt09sAiGcsTz_BnRJ_hxFVdjN4A@mail.gmail.com> from "Adam Langley" at Sep 26, 11 08:56:43 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:19:44 -0000

Adam Langley wrote:
> 
> On Mon, Sep 26, 2011 at 7:44 PM, Eric Rescorla <ekr@rtfm.com>; wrote:
> > I've taken an initial crack at a draft for this:
> > http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt
> 
> In Table 1 you list TLS 1.1 twice.

2nd column in EKRs draft in front of [RFC5246]? probably simple typo.

And while in theory I do not see a need for a SSLv3 SCSV in EKRs
proposal, it would allow testing the processing of this SCSV
even before implementing TLSv1.2 -- because to test with some
amount of certainty you need your code to support at least
two different versions.


> 
> It has been suggested by Yngve that the existing SSLv3, renego SCSV be
> used to indicate TLS 1.0 support. That's something that I suspect we
> will try.

I'm confused.  SSLv3-only servers (or TLS Servers limited to SSLv3 for
whatever administrative reason) are explicitly allowed to support
TLS renegotiation!

If your client creates and persists longs lists of server properties
so that it may connect in the future without having to go through
a TLS handshake failure and app-level reconnect fallback, then
this may be of help.

The idea behind doing TLS version proposal through a TLS cipher suite
to allow simple TLS clients, that neither persist server feature
characteristics nor contain a reconnect fallback, to succeed
the TLS handshake and use TLSv1.1 without having to worry about
handshake failures from version-intolerant Servers (independent
of whether they choke on ClientHello.client_version > TLSv1.0
or whether they do an incorrect RSA premaster secret client_version check.


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


Correct, this requirement in EKRs proposal is quite counter-productive
to the problem and needs to be removed.

I would actually prefer not to see any "MUST abort" in that document...


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

Correct.  The ClientHello.client_version = { 0x03, 0x01 } is sent
to keep the potentially version intolerant installed base working,
the TLS 1.1 or TLS 1.2 SCSV is sent to negotiate 1.1 or 1.2 with
peers supporting this scheme in spite of the conservative
ClientHello.client_version.

-Martin