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: =?utf-8?Q?Ivan_Risti=C4=87?= <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