[TLS] TLS protocol version intolerance [Was: Re: Deployment ... Re: This working group has failed]

Ivan Ristić <ivan.ristic@gmail.com> Tue, 19 November 2013 13:13 UTC

Return-Path: <ivan.ristic@gmail.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 7A3321ADFAA for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 05:13:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 outewNFvv77M for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 05:13:09 -0800 (PST)
Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 828D41ADFA9 for <tls@ietf.org>; Tue, 19 Nov 2013 05:13:09 -0800 (PST)
Received: by mail-ea0-f179.google.com with SMTP id r15so3125012ead.38 for <tls@ietf.org>; Tue, 19 Nov 2013 05:13:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=5SbiIuKTw7lanhlzvE4ZWGzJsS47KL1oeGfseI1yfok=; b=OWrhRzPOCv4ITeY8r6zmIgNJdqkmn9UkVGQzRWyIkEbVdrv/Hej7VX50g2HWAfzt6m cnpzzsOBJBDolpxc7OJVLFtxNX2lO5A3qbOv4ZK6ouIjseDOVCLFNWqniaBVe/tJ1CYX ocXfIx50EjxilumnN9Ak7uwnNJOsvG3NDc/bL68huHuKqfCgE+SPB0HRaIVcqt06ullh 6jBZWBqtKBEH9uFFxFvyXMfCL8fSJAprEYKbYv6u3AKydDZgVOvRrAg5pO0gnrHwLbrD +15nxBoxWd5IU3WpCZzRJNa8Ivy+X38IDNshYvUhKzxReUmosYCw8puGB9EoCHcWOZHO XyEg==
X-Received: by 10.14.88.132 with SMTP id a4mr2906320eef.60.1384866783093; Tue, 19 Nov 2013 05:13:03 -0800 (PST)
Received: from [192.168.0.8] (97e1a0f8.skybroadband.com. [151.225.160.248]) by mx.google.com with ESMTPSA id w6sm48697359eeo.12.2013.11.19.05.13.01 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 05:13:02 -0800 (PST)
Message-ID: <528B63DC.3050207@gmail.com>
Date: Tue, 19 Nov 2013 13:13:00 +0000
From: =?UTF-8?B?SXZhbiBSaXN0acSH?= <ivan.ristic@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: tls@ietf.org
References: <20131118192532.9CE531AAB0@ld9781.wdf.sap.corp>
In-Reply-To: <20131118192532.9CE531AAB0@ld9781.wdf.sap.corp>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [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 13:13:11 -0000

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