Subject: [ietf-tls] Re: Re: London

From: Eric Rescorla <[email-masked]>
Date: 16 Jul 2001 07:59:08 -0700

Bodo Moeller <[email-masked]> writes:
> Which one?  RFC 2246 appendix E says that the SSL 3.0 record format
> should be used for connection attempts if SSL 3.0 backwards
> compatibility is desired.  Thus 'version' in the record headers ('The
> version of the protocol being employed') should be {0x03, 0x00}, while
> 'client_version' in the actual ClientHello message ('The version of
> the TLS protocol by which the client wishes to communicate during this
> session') must be {0x03, 0x01}.  Of course, as long as ClientHello
> formats stay consistent, servers can simply ignore the minor digit of
> the record header 'version' field.
Actually, I'm not sure that I read it this way. Here's the text:

   TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both
   is easy. TLS clients who wish to negotiate with SSL 3.0 servers
   should send client hello messages using the SSL 3.0 record format and
   client hello structure, sending {3, 1} for the version field to note
   that they support TLS 1.0. If the server supports only SSL 3.0, it
   will respond with an SSL 3.0 server hello; if it supports TLS, with a
   TLS server hello. The negotiation then proceeds as appropriate for
   the negotiated protocol.

It seems to me that one could read this as indicating that you should
use the SSLv3 record format but substitute the version field (which
would make it the TLS record format, I suppose). Perhaps we should
ask what the desired behavior is so we can fix it before we go to Draft.

> >> With ClientHellos built like this, IE avoided the bug in servers that
> >> use 'version' where they should use 'client_version' -- in those
> >> ClientHellos, these two were the same value, after all.
> 
> > As I understood it, the client_version/version problem was about
> > checking in the PMS decryption process. Is there any server which
> > is confused about version checking in the record layer?
> 
> I'm not sure I understand this question.  If a server uses 'version'
> instead of 'client_version' for premaster secret decryption
> verification and the values odiffer, then the handshake quite simply
> will fail.
There are a number of values to consider
(1) The version number in the record header of the client_hello
(2) The version number in the client_hello message (the client_version)
(3) The negotiated version (in the server_hello)
(4) The version number in the record header of server_hello
and subsequent messages.
(5) The version number in the PMS.

The client is supposed to use value 2 in the PMS. I would expect
the server to compare it against either value 2 (correctly) or
value 3 (incorrectly). In either case, I don't see why the contents
of the client_hello record header should cause a problem for this
comparison.

On the other hand, the server might check value 1 against his
highest supported version and send an alert prior to sending the
server hello.

Have I missed something?

-Ekr

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