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

["Yngve N. Pettersen" <[e-mail]>]

On Mon, 26 Sep 2011 16:27:41 +0200, Martin Rex <[e-mail]> wrote:

> It seems that no TLS client that propose TLSv1.1 or higher today
> would want to do so without a reconnect fallback facility in place.
> The problem of the reconnect fallback is, that it precludes a protected
> negotiation of the TLS version.

As long as there is no way to tell if a server is negotiating version  
correctly, then we do need a fallback mechanism.

It is, however, a mechanism that for HTTPS, at least, is becoming less  
needed, as I indicated earlier in this thread.

I also think we have a mechanism now that can be used as an indicator that  
the server can negotiate version in the required fashion, without needing  
a fallback system: The Renegotiation Indication Extension.

The Renego specification contain a reminder about version and extension  
tolerance being required. (Yes, I lobbied for the inclusion of that  
particular text).

My testing indicates that the tolerance is included in most Renego patched  
servers. The failure rate in my sample is 0.092% up to and including TLS  
1.2, mostly extension intolerance. The version intolerance for version  
code 3.x >= 3.4 is 0.049%. There is some problems with the 4.x+ range,  
though, due to a missing patch at at least one vendor.

(To compare the numbers, this is slightly less than the number of servers  
that may break if the patch suggested for the BEAST issue is implemented,  
according to my testing.)

My suggestion is that clients that use a fallback policy to an older  
version than their highest supported version, in case negotiation fails,  
should always negotiate with their highest version indicated if the server  
is detected as having been Renego patched, and then not fall back in case  
negotiation fails.

That would essentially eliminate the version rollback potential, at least  
without a weakness being discovered in the protocol integrity check itself.

One way to implement such a policy is that the client starts with TLS 1.0  
+ extensions, and only upgrade to TLS 1.1 or TLS 1.2 if it detects that  
the server is renego patched.

Alternatively (and I prefer this), the client can start with a higher  
version, and fall back as needed (currently for 1.8% of the sites), but go  
back up if the server is detected as Renego patched. This would have the  
benefit that the client saves time when connecting to 98+% of the servers,  
by not needing a fallback or an upgrade in a new connection.

Currently, 30% (463) of the (max) TLS 1.1 servers are not renego patched  
servers, only a single of the 133 registered TLS 1.2 servers isn't  
patched. This group is 0.2% of the unpatched servers (39.9%).

I doubt that any other mechanism will work better, and deployment will be  
at least 3 years behind the Renego curve, and will probably have a lower  
server deployment rate than Renego.

Let's see if we can work with what we have, before we design a new  
mechanism.

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************