Re: [TLS] 1.0 or else (was Re: Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00)

[[e-mail] (Martin Rex)]

Martin Thomson wrote:
> Martin Rex <[e-mail]> wrote:
>> That's not quite true.  There es little, if any stuff outside of the
>> browser world that could go to > extension-less TLSv1.0, because there
>> are still too many servers out there that will abort the handshake
>> when extensions are present or when the version is > TLSv1.0.
> 
> Our limited survey thus far has identified only a small number (0.27%)
> of sites [1][2] that can't handle our TLS 1.2 handshake [3], even
> though they will tolerate our TLS 1.0 handshake.  In contrast,
> disabling SSL3 affected more than twice this amount.


For our TLS client and our customers, the amount of public Websites
with TLS extension or TLS version intolerance is not very meaningful.

We do _not_ provide a browser.  Our customers are using our TLS client
for programmatic data exchange scenarios.  Historically most was PKCS7,
but newer scenarios often use WebService/SOAP.  However, we know very
little about our customers' usage scenarios, except that we are
not permitted to break it with software updates.


A while ago I mentioned this site:
http://www.elemica.com/

which uses TLS-protected data exchange, authenticated by SSL client certs,
on the following endpoints:
     https://preprod.connect.elemica.com:5443
     https://connect.elemica.com:5443

both of these (TLSv1.0) services are TLS version tolerant,
but will abort the handshake with a fatal unexpected_message alert
when the ClientHello contains *any* TLS extensions.

This server/service became known to me only by coincidence.  For a short
time, the service seems to have been selecting a TLS cipher suite that
our TLS client did not propose.  A customer reported the interop problem
because it affected a production scenario. But when I analyzed the
scenario, I could no longer reproduce that handshake failure with our
client.

Reproducing handshake failures with OpenSSL is trivial, though.
It seems impossible to have the openssl 1.0.1 s_client send an
extension-less TLS ClientHello. (only 0.9.8 s_client with "-no_ticket").


We will not be able to ship any substantial change in client behaviour
as default behaviour, but will have to limit it to "explicit customer opt-in"
-- which means that the vast majority of customers will not use it.

Substantial changes that are well known to cause interop problems are
 - use of TLS extensions in initial ClientHello
 - use of ClientHello.client_version > (3,1) for initial ClientHello
 - use of record layer protocol version other than (3,0) or (3,1)
   for initial ClientHello

adding a small number of TLS cipher suites IDs to ClientHello creates
only a manageable risk (rfc5746 did not cause any interop problems).


This is why I would really appreciate a mechanism bein standardized
similar to the one described in this message:

http://www.ietf.org/mail-archive/web/tls/current/msg11238.html

One additional round-trip is a completely negligent price for
full interop.  Heavily used communication links see a
ratio of session resumes vs full handshakes of 10:1 to 50:1,
so most of the time, the additional round trip on a clean
initial handshake will not matter anyway.  With the information
stored in the existing regular client-side TLS session cache,
the fall-forward strategy can also be avoided.  No additional
heuristics nor additoinal per-server caching of meta-data necessary.


-Martin