Re: [TLS] One approach to rollback protection

Eric Rescorla <ekr@rtfm.com> Tue, 27 September 2011 01:12 UTC

Return-Path: <ekr@rtfm.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 95F5821F8D72 for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 18:12:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.895
X-Spam-Level:
X-Spam-Status: No, score=-102.895 tagged_above=-999 required=5 tests=[AWL=0.082, 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 af+g0AGWOVJj for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 18:12:26 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D25FF21F8D6C for <tls@ietf.org>; Mon, 26 Sep 2011 18:12:25 -0700 (PDT)
Received: by wyh21 with SMTP id 21so4884710wyh.31 for <tls@ietf.org>; Mon, 26 Sep 2011 18:15:09 -0700 (PDT)
Received: by 10.227.178.141 with SMTP id bm13mr3362396wbb.33.1317086109216; Mon, 26 Sep 2011 18:15:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.227.151.205 with HTTP; Mon, 26 Sep 2011 18:14:29 -0700 (PDT)
In-Reply-To: <201109270048.p8R0m3pJ013743@fs4113.wdf.sap.corp>
References: <CABcZeBNvASxnr1uzkP38_T2A0foYVUnz6UQhK8kH1yO=b8qLOw@mail.gmail.com> <201109270048.p8R0m3pJ013743@fs4113.wdf.sap.corp>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 26 Sep 2011 18:14:29 -0700
Message-ID: <CABcZeBMsKoK8swKpB=_wEovt0aiAdE7NUAFZ+y=Oa0kAdepZTQ@mail.gmail.com>
To: mrex@sap.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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
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:12:26 -0000

On Mon, Sep 26, 2011 at 5:48 PM, Martin Rex <mrex@sap.com>; wrote:
> Eric Rescorla wrote:
>>
>> Hmm... What's the advantage of something this complicated/expressive,
>> especially given that there is no way to currently express
>> "I speak TLS 1.2 but not 1.0"?
>
> I know that with "current TLS version negotiation" it is not possible
> to convey the exact protocol version that a clients supports or may
> want to talk.
>
> The issue with the original scheme is, that in order to offer TLSv1.2,
> you MUST (de facto) implement *ALL* prior protocol versions.
> But that currently means that you have to take all existing specs,
> put them side-by-side and work out the diffs yourself, because
> successors specs don't show the PDUs and semantics of previous
> protocol versions side-by-side.

I don't think I understand this: if you have a client which only wishes to
support TLS 1.2, what it currently does is to offer TLS 1.2 in the
ClientHello and then if the server selects a lower version in the
ServerHello, the client generates an error.

In an environment where the client could indicate any combination of
versions, the impact of implementing TLS 1.2 only would be that a
server which did not support TLS 1.2 would generate an error instead
of a ClientHello.

Since servers are supposed to select the highest common version, I'm
not sure I see serious difference between these two.


>> My objective here isn't to replace the TLS version negotiation mechanism
>> but merely to remove the downgrade attack problem. If we get that right,
>> and there is WG interest in revamping the version system, we can do that at
>> some other time.
>
> I don't think that revising the TLS version negotiation yet another
> time is a sensible idea.  If we do it at all, make it right this
> time.

I'm not sold that it's that lacking, other than the fact that people
have implemented
it wrong.

-Ekr