Re: [TLS] Open issue: Record Version Numbers

[Martin Rex <martin.rex@xxxxxxx>]

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.

There is one missing word in RFC-2246 Appendix E, but I argue that
it is a poor excuse for ignoring the quite clear comments on the
purpose of the two seperate version foelds (client version and
protocol version) where the actual data elements are defined.

As I wrote in early July, rfc 2246 Appendix E reads:

>    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.
 
the missing word is here:

    sending {3, 1} for the client_version field to note
                           ^^^^^^^
>
> The language about "should send client hello messages
> using the SSL 3.0 record format and client hello structure" could
> reasonably be read as merely indicating that you can't send anything
> that can't be parsed by following the SSL 3.0 specification and still
> expect an SSL 3.0 handshake to succeed, in particular given that
> RFC 2246 doesn't explicitly require TLS 1.0-only servers to tolerate
> {3,0} in record version numbers.

I'm sorry, but if interoperability with SSLv3 is desired, this is
a very obvious implication.  And if "should send client hello messages
using the SSL 3.0 record format and client hello structure" isn't
clear, then I don't know what is clear.

Most, if not all protocol specs have defects or ambiguities.
The alleged ambiguity in Appendix E is fairly easy to figure by
doing a consistency check on the descriptions of the three
variants of version fiels "version, client_version, server_version"
throughout the document plus a grain of common sense.


The wording in rfc-2246 Appendix E suggests that this appendix was
written before TLSv1.0 was finalized, because it is vague in two
respects: it doesn't tell you wether the {3,1} record protocol differs
somehow from the {3,0} record protocol, and it doesn't tell you whether
the {3,1} ClientHello message differs from the {3,0} ClientHello
_structure_.

The record protocol NEVER EVER had a field to indicate the client_protocol
version in any version of the spec.  There are exactly two structures
to carry the client_version, the ClientHello and the PreMasterSecret.
And then there is the ServerHello structure which carries the
server(-selected/negotiated) protocol version.


This dicussion doesn't get us anywhere.  My proposal is to fix
the longstanding typo in Appendix E and to insert "client_"
where it has been missing.


-Martin


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