[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TLS] Open issue: Record Version Numbers



On Thu, Oct 19, 2006 at 08:11:33PM +0200, Martin Rex wrote:
> Bodo Moeller wrote:

>> Remember that the SSL 3.0 specification and RFC 2426 and RFC 4346 all
>> imply that the record version number field is the "highest version of
>> the protocol supported by the client" (E.1 read in conjunction with
>> A.1.1 or A.1).

> Quite to the contrary.

I am fully aware that language has been added in RFC 2426 and RFC 4346
that indicates that the record version number field should be be
{3, 0} for backwards compatibility.  However, here I was explicitly
referring to Appendix E.1, which consistently has said something else;
look at the SSL 3.0 specification, or at RFC 2426, or at RFC 4346.

Yes, perfect specifications probably would always have said that the
record version number field should use the lowest protocol version
supported by the client.  Well, but the SSL 3.0 specification didn't
do this, the TLS 1.0 specification arguably tried to do it, and the
TLS 1.1 specification again failed to do so!

If as a client you want to offer the choice between TLS 1.0 and
TLS 1.1, then according to RFC 4346 you should ("SHOULD", even) use
the SSL 3.0 record format, which would imply sending {3, 0} as the
record version number even though {3, 0} does not designate a protocol
version supported by the client!

So, after all, the presence of {3, 0} in the record protocol of the
client hello message is *not* a reliable indicator for the server that
the client is going to agree to a SSL 3.0 handshake ...  This is
something we had agreed upon before, but I have to take this back, at
least if implementors take this part of RFC 4346 that seriously.

What remains is my main conclusion that the language in the
specification in this regards is a total mess, and that we can't just
look what we would *like* the specification to be, but mostly at what
will work best with the implementations that are actually out there.


>                                          My proposal is to fix
> the longstanding typo in Appendix E and to insert "client_"
> where it has been missing.

I totally agree to this.  It is absolutely clear that Appendix E
should mention client_version explicitly when saying where the client
must put the highest supported version to be used for key agreement.

Bodo


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