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

[Martin Rex <[e-mail]>]

Yngve N. Pettersen wrote:
> 
> Martin Rex wrote:
> > 
> > When sending an SSLv3 ClientHello (i.e. {0x03,0x00} at the record layer),
> > how many servers abort immediately, depending on the value of the
> > client_version:
> >
> >     for client_version = { 0x03,0x00 }   (SSLv3)
> >     for client_version = { 0x03,0x01 }   (TLSv1.0)
> >     for client_version = { 0x03,0x02 }   (TLSv1.1)
> >     for client_version = { 0x03,0x03 }   (TLSv1.2)
> >
> > and how many continue the handshake but fail the finished macs?
> 
> I am currently not registering data that detailed (although I do register  
> results for each tested client_version value tested, the results are not  
> that fine-grained), and IMO it does not really make that much a difference  
> (to the client) if the server just shut down the connection, or failed the  
> finished message; establishing the connection still failed.

Thank you very much for providing the information that have collected.
It's not that I urgently need exactly that information.  I'm mainly
trying to figure out what is the most interoperable set of "features" for
a ClientHello for a TLS client that is _not_ capable of reconnect fallback.

> 
> The number of servers that require the RSA client key exchange version  
> field to be the same as the negotiated version, not sent version, is about  
> 4.6% (April 2011; data not reliable since then :( ): about 27% ignore that  
> version field.

Thank you very much for reminding me of this problem.  I had entirely
forgotten about this, and that number (4.6%) is quite disappointing.

Add to that the RSA client key exchange version bug that Microsoft
has shipped with Windows 7 SChannel for the renegotiation handshake,
where they check the premaster secret version against the proposed
version of the initial handshake instead of the proposed version
of the current handshake and you will get the bottom line that
suggesting the use of TLS version 1.1 or 1.2 through
ClientHello.client_version will result in a significant amount
of interop problems.

I really think we (the TLS WG) should provide a remedy to this awful
situation for the TLS protocol version negotiation in the installed base.


> 
> As mentioned earlier I do register servers that refuse to accept a SSL v3  
> record protocol for the Hello, but require a TLS 1.0 instead (the number  
> of servers that require that, and are included in the above version  
> intolerance count is 29, 0.005 percentage points)

OK.  I personally don't see those as a problem because I consider
SSLv3 and TLSv1.0 equivalent when used with any of the regular
SSLv3 cipher suites plus rfc3268 AES.
 
> 
> One case where we do (implictly) get a failure during the finished mac, is  
> for the 0.117% of servers that mirror any version back, even if they do  
> not support it.

While being technically different, those will likely be covered by
a fairly conservative strategy of exclusively using either

   SSLRecord.protocol         = { 0x03,0x00 } 
   ClientHello.client_version = { 0x03,0x01 }

or

   SSLRecord.protocol         = { 0x03,0x01 } 
   ClientHello.client_version = { 0x03,0x01 }

for a client without reconnect fallback.

-Martin