Re: [TLS] Open issue: Record Version Numbers

[Martin Rex <martin.rex@xxxxxxx>]

Bodo Moeller wrote:
> Eric wrote: 
> >> 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 fully agree with Eric.  This is the correct and most reasonable approach.

> 
> 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 violently disagree.

Although there are broken servers out there, the bug seems to result
in the negotiation of SSLv3 {3,0} instead of TLSv1 {3,1} if the
client uses the correct behaviour and places {3,0} in the record
protocol for backwards compatibility.  Although this might be
an undesirable result, it is neither a serious interoperability
problem nor a direct security vulnerability by itself.


However, the approach of the client using {3,1} in the record protocol
will rightfully cause some SSLv3-only Server to abort the handshake,
which amounts to a real interoperability problem, so clients ought
to be strongly discouraged from taking that approach.

Changing a spec to break interoperability with perfectly correct
(server) implementations (of SSLv3) is a pretty bad idea.


-Martin

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