Re: [TLS] Deployment ... Re: This working group has failed

[[e-mail] (Martin Rex)]

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