Re: [TLS] One approach to rollback protection

Martin Rex <> Tue, 27 September 2011 00:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40F591F0CAB for <>; Mon, 26 Sep 2011 17:45:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.055
X-Spam-Status: No, score=-10.055 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DEqlQSBeF0Dm for <>; Mon, 26 Sep 2011 17:45:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 880481F0C86 for <>; Mon, 26 Sep 2011 17:45:20 -0700 (PDT)
Received: from by (26) with ESMTP id p8R0m4dv003290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 02:48:04 +0200 (MEST)
From: Martin Rex <>
Message-Id: <>
To: (Eric Rescorla)
Date: Tue, 27 Sep 2011 02:48:03 +0200 (MEST)
In-Reply-To: <> from "Eric Rescorla" at Sep 26, 11 05:28:07 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Subject: Re: [TLS] One approach to rollback protection
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Sep 2011 00:45:21 -0000

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.

> 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

It is really much more important to do the interop testing before
implementations of this are shipped, than making it the most
simplistic change possible in order to obtain a protected negotiation.