Re: [TLS] Downgrade protection, fallbacks, and server time
mrex@sap.com (Martin Rex) Mon, 06 June 2016 16:25 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 C45E012D82D for <tls@ietfa.amsl.com>; Mon, 6 Jun 2016 09:25:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level:
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83aSZpZDO1tO for <tls@ietfa.amsl.com>; Mon, 6 Jun 2016 09:25:42 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CCF412D84B for <tls@ietf.org>; Mon, 6 Jun 2016 09:25:20 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 89AE644361 for <tls@ietf.org>; Mon, 6 Jun 2016 18:25:18 +0200 (CEST)
X-purgate-ID: 152705::1465230318-0000082D-1CCFF146/0/0
X-purgate-size: 3295
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 7BCA7428F4 for <tls@ietf.org>; Mon, 6 Jun 2016 18:25:18 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 492BD1A4E0; Mon, 6 Jun 2016 18:25:18 +0200 (CEST)
In-Reply-To: <A6E19341-DF55-478E-8776-082461477F62@dukhovni.org>
To: tls@ietf.org
Date: Mon, 06 Jun 2016 18:25:18 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20160606162518.492BD1A4E0@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/F5qk2TxoSC5oF71u93_KIff73N8>
Subject: Re: [TLS] Downgrade protection, fallbacks, and server time
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 06 Jun 2016 16:25:45 -0000
The IMO most reasonable way forward would be to side-step the TLS version negotiation through ClientHello.client_version entirely, because of the well-known interop problems. Simply use the presence of *ANY* TLSv1.2+ TLS cipher suite in the offered list of TLS cipher suites as an indication that a TLS client is capable and willing to actually _use_ TLSv1.2, even when ClientHello.client_version might indicate (3,2) or (3,1) for better interop. The same approach will work for TLSv1.3, where the presence of a TLSv1.3 could be used to tell the server that the client is capable and willing to talk TLSv1.3, even when ClientHello.client_version might indicate a lower version of the protocol. Only the client is in the position to decide whether aborting the TLS handshake and retrying with a more feature-creeping ClientHello could provide additional benefits to the client (that it previously didn't offer, for whatever reason), and only the client is in the position to know how many TLS handshake attempts with which properties it previously attempted, and when to better stop retrying automatically and silently and to perform risk management (such as warning user/admin that something odd is going on). To get a smooth migration to using newer TLS protocol versions, we first need to define a scheme that lets new implementations recognize each other without upsetting the installed base. We know what works, the code points already exist, we will just have to align the documented semantics to provide a more forward-interoperable and more reasonable behaviour. Viktor Dukhovni wrote: > >> David Benjamin <davidben@chromium.org> wrote: >> >> I'm not sure I follow. The specification certainly spells out how >> version negotiation is supposed to work. That hasn't stopped servers >> from getting it wrong. Fundamentally this is the sort of thing where >> bugs don't get noticed until we make a new TLS version, and we don't >> do that often enough to keep rust from gathering. > > A better way to keep rust from gathering is to not instutionalize fallback, > force the broken sites to deal with the issue. It's not the sites, but rather the software vendor providing the underlying TLS implementation. Sometimes you don't actually have a choice and an alternative to using what exists. > > While 2% is noticeable, you can probably drive 1.3 version intolerance > out of the ecosystem relatively quickly if Chrome implements fallback > for a limited time (say 6 months after TLS 1.3 RFC is done) and with > a diminishing probability (60% first month, 10% less each month > thereafter), season to taste. There exist various different flavour of TLS version intolerance, and the amount of defective servers out there is probably much larger. The entire installed base of Windows 2008R2 and Windows 20012R2 is TLS version intolerant with respect to TLSv1.2. If you send propose TLSv1.2 inside an SSLv2Hello to such a server, it will negotiate TLSv1.1 (rather than TLSv1.2). If you send an extensionless SSLv3 Hello proposing TLSv1.2, these Windows server with choke and close the network connection. An extension-less SSLv3 Hello with at client_version = TLSv1.1 or TLSv1.0 will succeed. -Martin
- Re: [TLS] Downgrade protection, fallbacks, and se… David Benjamin
- Re: [TLS] Downgrade protection, fallbacks, and se… Martin Rex
- [TLS] Downgrade protection, fallbacks, and server… David Benjamin
- Re: [TLS] Downgrade protection, fallbacks, and se… Eric Rescorla
- Re: [TLS] Downgrade protection, fallbacks, and se… David Benjamin
- Re: [TLS] Downgrade protection, fallbacks, and se… Eric Rescorla
- Re: [TLS] Downgrade protection, fallbacks, and se… Martin Thomson
- [TLS] no fallbacks please [was: Downgrade protect… Nikos Mavrogiannopoulos
- Re: [TLS] no fallbacks please [was: Downgrade pro… Yoav Nir
- Re: [TLS] Downgrade protection, fallbacks, and se… Hubert Kario
- Re: [TLS] no fallbacks please [was: Downgrade pro… Hubert Kario
- Re: [TLS] Downgrade protection, fallbacks, and se… David Benjamin
- Re: [TLS] Downgrade protection, fallbacks, and se… Viktor Dukhovni
- Re: [TLS] no fallbacks please [was: Downgrade pro… David Benjamin
- Re: [TLS] Downgrade protection, fallbacks, and se… David Benjamin
- Re: [TLS] Downgrade protection, fallbacks, and se… Hubert Kario
- Re: [TLS] no fallbacks please [was: Downgrade pro… David Benjamin
- Re: [TLS] Downgrade protection, fallbacks, and se… David Benjamin
- Re: [TLS] no fallbacks please [was: Downgrade pro… Hubert Kario
- Re: [TLS] no fallbacks please [was: Downgrade pro… Hubert Kario
- Re: [TLS] Downgrade protection, fallbacks, and se… Viktor Dukhovni
- Re: [TLS] no fallbacks please [was: Downgrade pro… Martin Thomson
- Re: [TLS] no fallbacks please [was: Downgrade pro… Dave Garrett
- Re: [TLS] no fallbacks please [was: Downgrade pro… Nikos Mavrogiannopoulos
- Re: [TLS] no fallbacks please [was: Downgrade pro… Ilari Liusvaara
- Re: [TLS] no fallbacks please [was: Downgrade pro… Hubert Kario
- Re: [TLS] no fallbacks please [was: Downgrade pro… Xiaoyin Liu
- Re: [TLS] no fallbacks please [was: Downgrade pro… Hubert Kario
- Re: [TLS] no fallbacks please [was: Downgrade pro… Eric Rescorla
- Re: [TLS] no fallbacks please [was: Downgrade pro… Andrei Popov
- Re: [TLS] no fallbacks please [was: Downgrade pro… Eric Rescorla
- Re: [TLS] no fallbacks please [was: Downgrade pro… Viktor Dukhovni
- Re: [TLS] no fallbacks please [was: Downgrade pro… David Benjamin
- Re: [TLS] no fallbacks please [was: Downgrade pro… Dave Garrett
- Re: [TLS] no fallbacks please [was: Downgrade pro… Bill Frantz
- Re: [TLS] Downgrade protection, fallbacks, and se… Yaron Sheffer
- Re: [TLS] Downgrade protection, fallbacks, and se… Stefan Winter
- Re: [TLS] no fallbacks please [was: Downgrade pro… Hubert Kario
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Peter Gutmann
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Peter Gutmann
- Re: [TLS] no fallbacks please [was: Downgrade pro… Dave Garrett
- Re: [TLS] no fallbacks please [was: Downgrade pro… Jeffrey Walton
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Peter Gutmann
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Kyle Rose
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Hubert Kario
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Yoav Nir
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Salz, Rich
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Yoav Nir
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Hubert Kario
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Yoav Nir
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … David Benjamin
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Andrei Popov
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Yuhong Bao
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Dave Garrett
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Hubert Kario
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Hubert Kario
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Nikos Mavrogiannopoulos
- Re: [TLS] no fallbacks please [was: Downgrade pro… Tony Arcieri