Re: [TLS] One approach to rollback protection

Martin Rex <mrex@sap.com> Thu, 29 September 2011 14:58 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 0EF2C21F8D16 for <tls@ietfa.amsl.com>; Thu, 29 Sep 2011 07:58:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.067
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vl8BHqTyhj-I for <tls@ietfa.amsl.com>; Thu, 29 Sep 2011 07:58:00 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 544FE21F8C9B for <tls@ietf.org>; Thu, 29 Sep 2011 07:58:00 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (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 <mrex@sap.com>
Message-Id: <201109291500.p8TF0Spb013525@fs4113.wdf.sap.corp>
To: nmav@gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 29 Sep 2011 17:00:28 +0200 (MEST)
In-Reply-To: <4E841253.9060605@gnutls.org> 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
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: 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
available.


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


-Martin