Re: [TLS] Open issue: Record Version Numbers

[Bodo Moeller <bmoeller@xxxxxxx>]

> Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx> writes:

>> Yngve Petterson has pointed out [0] that there is some confusion
>> in how to interpret what version numbers ought to appear in
>> the ClientHello record in TLS handshakes. [...]
>>    "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".	
>>
>> I read this text as saying that if you are a client who supports TLS 1.0
>> and SSLv3, you should in general send the following values:
>>
>> - record version number           {3, 0} (SSLv3)
>> - client hello version number     {3, 1} (TLSv1)
>>
>> If the server decides to accept TLS 1.0, it should respond with the
>> following values:
>>
>> - record version number           {3, 1} (TLSv1)
>> - client hello version number     {3, 1} (TLSv1)
>>
>> Pettersen reports that in some cases this causes errors because servers
>> (inexplicably) use the record version in the negotiation.  However, I
>> think at the end of the day, that's a clear implementation error
>> and the spec should just clarify that the above behavior is what's
>> expected.

I agree that, by the wording of the specification, clients in this
setting should send {3, 0} as record version number and {3, 1} as
client hello version number, and that it is a clear implementation
error if servers do not properly handle this.  However, since there
*are* servers showing this bug, it is reasonable for clients to send
{3, 1} for both the record version number and the client hello version
number.  (The specification text only says "should", not "MUST".)

I don't agree that the RFCs are totally clear about the situation: for
example, RFC 2246 says "a TLS server which wishes to interoperate with
SSL 3.0 clients should accept SSL 3.0 client hello messages", but does
not say that TLS servers who do *not* wish to interoperate with TLS
3.0 clients should accept SSL 3.0 client hello messages anyway (since
the actual client hello protocol version may be TLS 1.0).  This
requirement is a logical consequence if we want the protocol to work,
but this is something that should be worked out in the specification
and not left for implementors to derive.  The wording in RFC 4346
(TLS 1.1) is even less clear because it does not mention the TLS 1.0
backwards compatibility case.

The proper way to resolve the situation appears to be:

- Clients MAY (not "should") use the lowest supported protocol version
  for the record version number, and must use the highest supported
  protocol version for the client hello version number.

- Servers MUST accept any {3, ??} record version number for the client
  hello and interpret the client hello message according to their
  supported protocol versions.  If the client hello version number
  denotes a protocol version supported by the server, use this
  version.  Otherwise, if the client hello version number is higher
  than any protocol version supported by the server, use the maximum
  protocol version supported by the server.  In this case, if the
  client hello version number is different from the client's record
  version number, then the server MAY send a fatal protocol_version
  alert if this server protocol version is below both the client hello
  version number and the client's record version number.

With this rule, servers can use the information conveyed in the record
version number / client hello version number combination if there is
some useful information (i.e. if the client is using the record
version number to provide the least protocol version supported), but
still no harm is done if clients send the client hello version number
as record version number to avoid confusing buggy servers.

Bodo


_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls