Re: [TLS] One approach to rollback protection

Martin Rex <> Thu, 29 September 2011 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0EF2C21F8D16 for <>; Thu, 29 Sep 2011 07:58:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.067
X-Spam-Status: No, score=-10.067 tagged_above=-999 required=5 tests=[AWL=0.182, 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 vl8BHqTyhj-I for <>; Thu, 29 Sep 2011 07:58:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 544FE21F8C9B for <>; Thu, 29 Sep 2011 07:58:00 -0700 (PDT)
Received: from by (26) with ESMTP id p8TF0TRJ013274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 17:00:34 +0200 (MEST)
From: Martin Rex <>
Message-Id: <>
To: (Nikos Mavrogiannopoulos)
Date: Thu, 29 Sep 2011 17:00:28 +0200 (MEST)
In-Reply-To: <> from "Nikos Mavrogiannopoulos" at Sep 29, 11 08:38:11 am
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: Thu, 29 Sep 2011 14:58:01 -0000

Nikos Mavrogiannopoulos wrote:
> Martin Rex wrote:
> > 
> > I do _not_ want to retire the original TLS version negotiation,
> > just like to see an alternative "hinting" being standardized to
> > accomodate a ~10 year transition period to get over TLS version-related
> > interop problems that exist in today's installed base.
> For what reason? Since more and more people demand TLS 1.1 support more 
> and more servers will make sure that they interoperate with it.

More and more browsers support reconnect fallbacks for version-intolerant
and extension-intolerant servers -- and since it is impossible to
protect against attackers forcing that fallback, a browser implementing
and offering TLSv1.1 is *NOT* a solution to the problem at all.

Firefox added the reconnect fallback although it supports at most TLSv1.0
and only has to deal with the comparatively small extension-intolerant
servers.  As soon as browsers start sending TLSv1.1 or TLSv1.1 in
ClientHello.client_version, they will be faces with the much more
serious TLS version intolerance problem, in particular with respect
to incorrect RSA premaster secret client_version checks.

So for browsers -- the only clients that are affected by BEAST-style
attacks besides SSL-VPNs, there currently is no robust protection

> Creating a new approach to negotiate versions might even create more 
> interoperability problems. Why do you think implementers that got wrong 
> the original simple negotiation will get right this one?

Lack of testing (methodology).