Subject: [ietf-tls] Confusion with SSLv2 backward compatibility

From: Eric Rescorla <[email-masked]>
Date: Wed, 01 Nov 2000 18:59:54 -0800

In Appendix E, RFC 2246 lists the following 7 cipher suites as 
"carryovers from SSL Version 2.0". 

-----snip-----
   The following cipher specifications are carryovers from SSL Version
   2.0. These are assumed to use RSA for key exchange and
   authentication.

       V2CipherSpec TLS_RC4_128_WITH_MD5          = { 0x01,0x00,0x80 };
       V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
       V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5  = { 0x03,0x00,0x80 };
       V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
                                                  = { 0x04,0x00,0x80 };
       V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5     = { 0x05,0x00,0x80 };
       V2CipherSpec TLS_DES_64_CBC_WITH_MD5       = { 0x06,0x00,0x40 };
       V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };

   Cipher specifications native to TLS can be included in Version 2.0
   client hello messages using the syntax below. Any V2CipherSpec
   element with its first byte equal to zero will be ignored by Version
   2.0 servers. Clients sending any of the above V2CipherSpecs should
   also include the TLS equivalent (see Appendix A.5):
------snip-----
Nw, it's not clear how to interpret this. One interpretation is that
the server should IGNORE any SSLv2 cipher suites that aren't obviously
TLS cipher suites, but then why bother to list these at all, especially
as "carryovers"? 

Another possible interpretation is that a TLS implementation receiving
one of these cipher suites should map it to its TLS equivalent. I seem
to remember at one point seeing an implementation send an SSLv2 cipher
suite but not its SSLv3 equivalent and one might expect a liberal server
to negotiate that. However, this too is problematic because the RC2-128
cipher suite has no equivalent in TLS and the DES, 3DES, and IDEA cipher
suites in TLS use SHA-1, which I would argue makes them not equivalent

All in all, it's not obvious (at least to me) what to do. This issue
should be clarified before we take TLS to draft. I would favor simply
saying that TLS servers should ignore SSLv2 cipher suites which don't
have a leading zero (and therefore aren't TLS cipher suites presented
as cipher specs.).  Does anyone depend on this behavior in any way?

-Ekr

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

---

From: [email-masked] (Nelson Bolyard)
Date: Thu, 02 Nov 2000 17:01:10 -0800

> TLS cipher suites, but then why bother to list these at all, especially

A TLS server that supports client hellos in the SSLv2 format presumably 
does so because it wants to be compatible with clients that support SSLv2
as well as TLS.  Such clients are likely to include both SSLv2 "cipherspecs"
and TLS ciphersuites in the same client hello, so that they can interoperate
with both SSLv2 servers and SSL3/TLS servers without having to know the
capabilities of any server, a priori.  

If the client hello in SSLv2 format indicates that the client supports TLS,
then IMO the TLS server should ignore the SSLv2 cipherspecs.  

If the client hello in SSLv2 format indicates that the client only 
understands SSLv2, then the server's response obviously depends on whether 
or not the server implements SSLv2.

I suspect these cipher specs are listed in RFC 2246 because they were 
originally listed in the SSL 3.0 draft from which RFC 2246 evolved.  
(See appendix E in http://home.netscape.com/eng/ssl3/draft302.txt).

I believe they were listed in the SSL 3.0 draft simply to set the SSL 3
developers' expectations for what might be present in the v2 client hello 
in addition to the SSLv3 ciphersuites.  Listing them in the SSL 3.0 draft
obviated a citation for the SSLv2 specification, which was even more 
controversial.

> to negotiate that. 

I believe it would be an error to negotiate a ciphersuite not listed 
explicitly in the client hello.  I don't know of any servers that do that.

> should be clarified before we take TLS to draft. 

Is anyone acting as editor for the purpose of taking TLS to draft?

There are quite a number of such issues that have been raised in this 
mailing list in the last year or so.  They've ranged from obvious, 
non-controversial things (e.g. the reference to SSL3's Sender.server 
and Sender.client, which are undefined in TLS, in section 7.4.9) to more 
difficult topics like the negotiation of different versions of SSL/TLS 
in handshakes subsequent to the first one on a TLS connection.  But I've
never seen a new draft of the TLS spec that incorporates any of the 
suggested changes.

--
Nelson Bolyard  
Disclaimer:                  I speak for myself, not for Netscape

---

---

From: Eric Rescorla <[email-masked]>
Date: 02 Nov 2000 20:22:55 -0800

> capabilities of any server, a priori.  
Naturally.

> then IMO the TLS server should ignore the SSLv2 cipherspecs.  
That's certainly the most obvious interpretation.

> explicitly in the client hello.  I don't know of any servers that do that.
Ok. I'm all for not doing this (despite the fact that I had a brain
fart and managed to say otherwise in the relevant section of my
book :))

-Ekr

---