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
Date: Thu, 29 Sep 2011 17:00:28 +0200
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
- [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Nico Williams
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Adam Langley
- Re: [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Adam Langley
- Re: [TLS] One approach to rollback protection Marsh Ray
- Re: [TLS] One approach to rollback protection Juho Vähä-Herttua
- Re: [TLS] One approach to rollback protection Nikos Mavrogiannopoulos
- Re: [TLS] One approach to rollback protection Yoav Nir
- Re: [TLS] One approach to rollback protection Dan Winship
- Re: [TLS] One approach to rollback protection Nikos Mavrogiannopoulos
- Re: [TLS] One approach to rollback protection Badra
- Re: [TLS] One approach to rollback protection Matt McCutchen
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Yngve N. Pettersen
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Nikos Mavrogiannopoulos
- Re: [TLS] One approach to rollback protection Martin Rex