Re: [TLS] interop for TLS clients proposing TLSv1.1

[Martin Rex <[e-mail]>]

Yoav Nir wrote:
> 
> Yngve N. Pettersen (Developer Opera Software ASA) wrote:
> >
> > Martin Rex <[e-mail]> wrote:
> > >
> > > Does anyone (SSL Labs, Opera, others) have any figures/stats about the
> > > current "TLSv1.1 version (in)tolerance" for TLS servers on the public
> > > internet?
> > 
> > This week's test of 609726 servers gave these numbers:
> > 
> >   * 1.145% of the probed servers were version intolerant for at least one  
> > of the current TLS versions (1.0, 1.1, 1.2)
> >   * 1.742% were extension intolerant for the same versions
> >   * 1.136% belonged in both groups
> > 
> > This gives an estimated total of 1.751% that are either version and/or  
> > extension intolerant for the currently defined TLS versions.
> > 
> > These numbers have been decreasing during the past year and a half, around  
> > January 2011 it was 1.951% just for the version intolerant, 2.657% in may  
> > 2010 (the extension numbers are not as detailed for those runs).
> > 
> > Most of the version intolerant are intolerant for TLS 1.1 and TLS 1.2, but  
> > some are SSLv3 only servers that are also intolerant for TLS 1.0. There is  
> > even a 0.007% share that support TLS 1.1 (quite a lot of which has "vpn"  
> > as the hostname).
> 
> By "version intolerant" do you mean that you're sending a TLS 1.1
> or 1.2 handshake message and the server rejects it?

> 
> If you send a TLS 1.0 handshake message, with the version field of the
> ClientHello showing 1.2, what portion of the servers would reject that
> (rather than just replying in TLS 1.0)?

The latter is what I'm actually interested in
(but seem not have been sufficiently clear about).

Sending TLSv1.1 or TLSv1.2 in the Record Layer for ClientHello
constitutes a version-intolerant client (or more appropriately
it indicates a client that is unwilling to talk TLSv1.0).

Other than a very last resort in trying to get a TLS handshake succeed
I see little value in sending a value above TLSv1.0 in the protocol
version field of the SSL3 Record carrying the initial ClientHello
on a connection.


> 
> If the portion is very low, it could be feasible to implement a
> client without fallback behavior.

Since "fallback behaviour" is dumped entirely on the app calling
the TLS implementation, I expect "clients without fallback behaviour"
to be the norm for programmatic clients.

The version intolerance stats for public servers on the internet
is not really representative.  I expect a significant amount of
version-intolerant servers to not be publicly accessible.


I'm seeing a desire to raise the number of TLS peers use TLSv1.1
with CBC-based cipher suites and explicit IVs, and I'm also
seeing a residual, non-negligible number of version intolerant
TLS servers interfering with original design of TLS protocol
version negotiation.

I would appreciate a solution for decoupling of these two
issues so that clients without fallback capabilities
become able to use TLSv1.1 right away, while neither facing
new interop problems or having to wait 5+ years for sufficient
of the version intolerant TLS servers to die.


-Martin