Subject: [ietf-tls] The https client TLS deployment dilemma

From: [email-masked] (Nelson Bolyard)
Date: Tue, 10 Oct 2000 17:02:59 -0700

Today a substantial percentage of the https/SSL servers out there do not 
successfully negotiate an SSL3 session with a standard-compliant TLS/SSL3
client.  This includes servers run by large fortune 500 corporations,
as well as smaller web sites.  Let's call these server "TLS intolerant".

These servers REQUIRE that the value presented in the client_version 
field of the PreMasterSecret component of the ClientKeyExchange message
contain exactly 0x0300, and they will not complete an SSL/TLS handshake
if it contains any other value.  

The TLS spec requires (and it was also the intent of the SSL3 spec) that
the client_version field in the RSA encrypted premaster secret exactly
match the value sent by the client in the ClientHello message.  So a 
spec-compliant TLS/SSL client will send 0x0301 in the client_version 
fields of both the ClientHello and the ClientKeyExchange messages, even
if it negotiates down to SSL3 (0x0300) in the ServerHello message. 

A client that behaves that way (following the spec) will not interoperate
with the servers described above.  To an end user, such a client product
will appear to be defective, buggy, at fault, when in fact it is correct.

One extant client product that claims to support TLS apparently sends the
negotiated protocol version number, not necessarily the version number it 
sent in the ClientHello message, to the server in the client_version field 
in the RSA-encrypted pre-master secret message.  Besides not being spec
compliant, this behavior makes roll-back detection impossible.  

But that client does interoperate with the "TLS Intolerant" SSL3 servers
mentioned above. To an end user comparing that product with one that 
follows the spec strictly, that client product appears to be superior, 
because it interoperates with a larger number of servers.

The dilemma:

If https client vendors today wish to deploy TLS (as well as SSL3) in 
their client products, their choices appear to be:

a) Implement TLS per the spec, and don't interoperate with a large number
   of servers out there, and thereby appear to be inferior to the products
   that do interoperate with those "TLS Intolerant" servers, or

b) Implement TLS, but send the negotiated protocol version in the pre-master
   secret message.  This is not spec compliant, but interoperates with more
   servers than choice a above, and is seen as superior by end users.  

c) Wait until either (A) most of the "TLS intolerant" servers are replaced, 
   or (B) all (or most) other https clients out there follow the TLS spec, 
   thereby leveling the field for https clients, or (C) until some other 
   as-yet-unseen market force creates a demand for TLS spec-compliant https
   clients.

Issues like this one must be resolved before the world will switch from
SSL3 to TLS.

--
Nelson Bolyard               Sun / Netscape Alliance
Disclaimer:                  I speak for myself, not for Netscape or iPlanet

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]