Re: [TLS] Open issue: Record Version Numbers

[Bodo Moeller <bmoeller@xxxxxxx>]

On Thu, Oct 19, 2006 at 03:59:53PM +0200, Martin Rex wrote:

>> I don't think arguing which of them does it "rightfully" is very
>> useful (as Bodo pointed out, TLS 1.0 spec does not say that TLS
>> 1.0-only servers should accept {3,0} in the record version);

> On the contrary.  The version on the record protocol is a PDU encoding,
> and TLS was specifically designed to reuse most of SSLv3.

Just like TLS 1.0 was designed to reuse most of SSL 3.0, SSL 3.0 was
designed to allow reuse in future protocol versions, and server
implementations of the SSL 3.0 specification should tolerate seeing
{3, 1} or later in the record version number used for the client
hello.  If implementations don't tolerate this, it is a deficiency,
just like it is a deficiency if TLS 1.0 implementations don't tolerate
{3, 0} in the record version number.  In neither case, it necessarily
deserves to be called a bug in the implementation since the actual bug
is the unclear language in the specifications.

Note that the SSL 3.0 specification (draft-freier-ssl-version3-02.txt)
can be read as implying that the record version number field will
contain the highest version of the protocol supported by the client,
not the fixed value {3, 0}.  Appendix E.1 (on the version 2 client
hello) has the following description:

     version           The highest version of the protocol supported
                       by the client (equals ProtocolVersion.version,
                       see Appendix A.1.1).

Appendix A.1.1 is on the record layer, not on the client hello;
App. E.1 could have said "equals ClientHello.client_version, see
Appendix A.4.1", but doesn't.  (The language that suggests that
TLS 1.0 servers may be doing better by sending {3, 0} in the record
version number, in contradiction to what is implied by E.1 and
A.1[.1], was only added with the TLS 1.0 specification, and only with
a fuzzy "should".)


> There is no requirement for a TLSv1 server to agree to talking
> SSLv3 {3,1}, but it certainly is required to parse the SSLv3
> record procotol without hitches!

This certainly would be a very reasonable requirement (as in the
reverse case of SSL 3.0 servers when faced with the TLS 1.0 record
protocol).  One problem is that the specification does not say that it
is a requirement.  The more important problem is that various fielded
servers don't behave as well as we would like them to (i.e. don't
handle {3, 0} cleanly), whereas SSL 3.0-only servers showing the
reverse problem (not handling {3, 1} cleanly) appear to be rather
rare.  Now it appears to be the case that most client implementations
offering both SSL 3.0 and TLS 1.0 do send {3, 1} as both the record
version number and the client hello version number, and appear to get
along quite well.  You could say that these clients focus on their
role as TLS 1.0 clients (trying to interoperate with buggy TLS 1.0
servers as well), and try to *also* be SSL 3.0 clients (but without
extra effort for interoperating with deficient servers).


Thinking of it, it might actually be best if some clients use the
highest supported version for the record version number, and others
use the lowest supported version there, because this diversity
increases the probability that server problems about not tolerating
"strange" record version numbers will be found and fixed.

Bodo


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