Re: [TLS] TLS protocol version intolerance [Was: Re: Deployment ... Re: This working group has failed]
Michael Sweet <msweet@apple.com> Tue, 19 November 2013 15:54 UTC
Return-Path: <msweet@apple.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2FB1ADF47 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 07:54:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.127
X-Spam-Level:
X-Spam-Status: No, score=-7.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 uXRH_QxEXtNl for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 07:54:52 -0800 (PST)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 91DB01ACC8B for <tls@ietf.org>; Tue, 19 Nov 2013 07:54:52 -0800 (PST)
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"
Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MWI00124PIUBYA1@mail-out.apple.com> for tls@ietf.org; Tue, 19 Nov 2013 07:54:43 -0800 (PST)
X-AuditID: 11807153-b7f246d000005e2f-40-528b89c2b667
Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id C3.7C.24111.2C98B825; Tue, 19 Nov 2013 07:54:42 -0800 (PST)
Received: from [17.153.62.85] by sesame.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MWI00H1RPJ4ZE50@sesame.apple.com> for tls@ietf.org; Tue, 19 Nov 2013 07:54:42 -0800 (PST)
From: Michael Sweet <msweet@apple.com>
In-reply-to: <528B63DC.3050207@gmail.com>
Date: Tue, 19 Nov 2013 10:54:40 -0500
Content-transfer-encoding: quoted-printable
Message-id: <1BFA59E4-7393-479A-A7C8-FBF2906795F6@apple.com>
References: <20131118192532.9CE531AAB0@ld9781.wdf.sap.corp> <528B63DC.3050207@gmail.com>
To: Ivan Ristić <ivan.ristic@gmail.com>
X-Mailer: Apple Mail (2.1824)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FDcoHuoszvIYO8mcYtP57sYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsXTZT8aCrwoVOy70sDUwXpLqYuTkkBAwkehYOZ8dwhaTuHBv PVsXIxeHkEAfk8SMye/ZIZw/jBIXltwBqxIWKJQ4sWM2M4jNK6An8W7NHaYuRg4OZgF1iSlT ckHCbAJqEr8n9bGC2JwCmhKHVv5nBLFZBFQlvm+eC9bKLCAgce7ZCyhbW+LJuwusECNtJFbc 6mIDsYUEoiQ2rHwCZosIWEgc63/JBrJKQkBW4l1z0ARGgVlIjpiFcMQsJEMXMDKvYhQoSs1J rDTWSywoyEnVS87P3cQIDrrC4B2Mf5ZZHWIU4GBU4uGd4N4VJMSaWFZcmXuIUYKDWUmEt6a+ O0iINyWxsiq1KD++qDQntfgQozQHi5I47yMfoGqB9MSS1OzU1ILUIpgsEwenVAPjxKg1nxYW 7Ys8Evnh1HtbgT9fVx5KnaRvs//Paak5uRIn5F/0mQSoVf7guZ6Xw35jwsuaW+tyT63L+zRX 0c1JRHfGstk7AgOzw36H6omZ/8marCW5ZY6Eh0Cet87pn9avf/burzya92ue27yEObw2Z/Va TV2bTrxcf86K8a/11gWsWQ2/AnsjlFiKMxINtZiLihMBBMv01zYCAAA=
Cc: tls@ietf.org
Subject: Re: [TLS] TLS protocol version intolerance [Was: Re: Deployment ... Re: This working group has failed]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Tue, 19 Nov 2013 15:54:54 -0000
Would a practical solution be to do a TLS 1.2.1 update that: 1. Keeps the same TLS version in the ClientHello as 1.2, 2. Adds new mandatory cipher suites (as needed), 3. Adds a fast negotiation extension (as needed/if possible), and 4. Deprecates (but does not remove) any 1.2 cipher suites we know to be broken. The goal would be backwards-compatibility with TLS implementations that support (or at least gracefully negotiate down from) 1.2. (IANAC (I am not a cryptographer), I just use a lot of TLS libraries and don’t know whether this is workable…) On Nov 19, 2013, at 8:13 AM, Ivan Ristić <ivan.ristic@gmail.com> wrote: > To add to this discussion about protocol version intolerance, I've been > tracking this problem in my SSL Pulse data set (SSL servers from the > Alexa top 1 million). > > Here's what I have for November: > > Total servers: 163,587 > > TLS 1.0 intolerance 9 > TLS 1.1 intolerance 1,388 > TLS 1.2 intolerance 1,448 (~ 0.9%) > TLS 1.3 intolerance 17,840 (~10.9%) > TLS 2.98 intolerance 122,698 (~75.0%) > > Long handshake intolerance: 4,795 (~2.9%) > > It seems to me that attempting to deploy TLS 1.3 would be very > difficult, considering how many servers are intolerant to this version > number. And TLS 2.x would be just hopeless. > > Disclaimer: I have not spent as much time as I would have liked > validating these, but I don't have a reason to believe they are not correct. > > > On 18/11/2013 19:25, Martin Rex wrote: >> Andrei Popov wrote: >>> >>> Yes, the percentage if servers that can't handle TLS1.2 or gracefully >>> negotiate a lower protocol version is diminishing, but very slowly. >> >> Unfortunately, I've seen a new (government mandated) Web Service usage >> scenario deployed in 2013 where the hardware SSL/TLS accellerater that >> is being used is TLS version intolerant to TLSv1.1 and TLSv1.2. >> >> >> We really need to get rid of the dependency on ClientHello.client_version >> being { 0x03, 0x03 } to use protocol features that can be implemented >> with fairly little effort in TLSv1.0, thereby obviating the need >> for reconnect fallbacks in clients -- a "feature" that most programmatic >> TLS clients do not have, and that is susceptible to downgrade. >> >> >>> >>> From my perspective, enabling TLS1.2 by default is necessitated >>> primarily by security and performance considerations (e.g. a chance >>> to negotiate AES_GCM instead of RC4). >> >> The interoperability problems from sending >> ClientHello.client_version { 0x03,0x03 } are to serious and significant >> to ignore, and the kludges (reconnect fallbacks) are to cumbersome >> for most apps. >> >> The _correct_ approach would be to publish how to use GenericAEADCipher >> record layer PDU and AES-GCM / AES-CCM with **ANY** version of TLS and >> remove the braindead "must not send this ciphersuite with client_version >> less that TLSv1.2" from the AES-CCM and AES-GCM documents. >> >> >> rfc5746 deployed with significantly less interop problems than both >> TLSv1.1 (rfc4346) and TLSv1.2 (rfc5246). >> >> >>> >>> However, for web browsers, enabling TLS1.2 by default means one more >>> step in the sequence of (insecure) reconnect attempts with lower >>> protocol versions. >> >> >> Rather than bulding such kludges into Browsers, the implementers >> should have come to the TLS WG help working on changes to TLS that >> will make all desired TLS features work in a more backwards compatible >> fashion than through kicking "client_version" / "protocol_version" fields. >> >> >> -Martin >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > -- > Ivan > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair
- [TLS] This working group has failed Watson Ladd
- [TLS] Deployment ... Re: This working group has f… Hannes Tschofenig
- Re: [TLS] Deployment ... Re: This working group h… Taylor Hornby
- Re: [TLS] This working group has failed SM
- Re: [TLS] This working group has failed Ralph Holz
- Re: [TLS] Deployment ... Re: This working group h… Hannes Tschofenig
- Re: [TLS] Deployment ... Re: This working group h… Yoav Nir
- Re: [TLS] Deployment ... Re: This working group h… Hannes Tschofenig
- Re: [TLS] This working group has failed Salz, Rich
- Re: [TLS] Deployment ... Re: This working group h… Mark Nottingham
- Re: [TLS] Deployment ... Re: This working group h… Kyle Hamilton
- Re: [TLS] Deployment ... Re: This working group h… Juho Vähä-Herttua
- Re: [TLS] Deployment ... Re: This working group h… Watson Ladd
- Re: [TLS] Deployment ... Re: This working group h… Salz, Rich
- Re: [TLS] Deployment ... Re: This working group h… Watson Ladd
- Re: [TLS] Deployment ... Re: This working group h… Salz, Rich
- Re: [TLS] Deployment ... Re: This working group h… Andrei Popov
- Re: [TLS] Deployment ... Re: This working group h… Martin Rex
- Re: [TLS] Deployment ... Re: This working group h… Martin Rex
- Re: [TLS] Deployment ... Re: This working group h… Watson Ladd
- Re: [TLS] Deployment ... Re: This working group h… Geoffrey Keating
- Re: [TLS] Deployment ... Re: This working group h… Michael Staubermann
- Re: [TLS] Deployment ... Re: This working group h… Martin Rex
- Re: [TLS] Deployment ... Re: This working group h… Joshua Davies
- Re: [TLS] Deployment ... Re: This working group h… Martin Rex
- Re: [TLS] Deployment ... Re: This working group h… Martin Rex
- Re: [TLS] Deployment ... Re: This working group h… Andy Lutomirski
- Re: [TLS] Deployment ... Re: This working group h… Kirils Solovjovs
- Re: [TLS] Deployment ... Re: This working group h… Andy Wilson
- Re: [TLS] Deployment ... Re: This working group h… Marsh Ray
- Re: [TLS] Deployment ... Re: This working group h… Ralf Skyper Kaiser
- Re: [TLS] Deployment ... Re: This working group h… Ben Laurie
- [TLS] TLS protocol version intolerance [Was: Re: … Ivan Ristić
- Re: [TLS] Deployment ... Re: This working group h… Zooko Wilcox-OHearn
- Re: [TLS] TLS protocol version intolerance [Was: … Michael Sweet
- Re: [TLS] TLS protocol version intolerance [Was: … Eric Rescorla
- Re: [TLS] Deployment ... Re: This working group h… Martin Rex
- Re: [TLS] Deployment ... Re: This working group h… Andy Lutomirski
- Re: [TLS] Deployment ... Re: This working group h… Martin Rex
- [TLS] multiple clients in one process (was: Re: D… Patrick Pelletier
- Re: [TLS] multiple clients in one process (was: R… Andy Lutomirski
- Re: [TLS] multiple clients in one process (was: R… Daniel Kahn Gillmor
- Re: [TLS] multiple clients in one process (was: R… Nico Williams
- Re: [TLS] multiple clients in one process (was: R… Nikos Mavrogiannopoulos
- Re: [TLS] multiple clients in one process (was: R… Andy Lutomirski