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

[Ivan Ristić <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
> 


-- 
Ivan