Re: [TLS] Open issue: Record Version Numbers

[Bodo Moeller <bmoeller@xxxxxxx>]

On Wed, Oct 18, 2006 at 08:48:29PM +0200, Martin Rex wrote:

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

Well, SSL 3.0 does have more severe security vulnerabilities than
TLS 1.0 (http://www.imc.org/ietf-tls/mail-archive/msg03983.html),
although these shouldn't be too significant for typical use.  Also,
in some cases draft-pettersen-tls-interop-experience-00.txt does
report connection abortions due to this bug that could be avoided
by sending {3,1} in both version fields.

My impression was that sending {3,1} in both fields is less
problematic in practice than sending {3,0} as the record version
number and {3,1} as the client hello version number.  However, this
may be based on an incomplete assessment of what servers are out
there, and more importantly, how current servers will react
to similar situations involving newer and future protocol versions,
such as {3,2} (TLS 1.1), {3,3} (TLS 1.2), and {3,42} (a made-up future
protocol version that should cause servers to negotiate an existing
version).


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

In my view the main problem is that the speficification never clearly
and fully described how implementations should behave to guarantee
interoperability.  Just like the SSL 3.0 specification does not
require servers (SSL 3.0-only servers, that is) to accept {03, 01} in
the record version number, the TLS 1.0 specification does not require
servers (TLS 1.0-only servers) to accept {03, 00}.  In both cases, it
is to be hoped that implementors are wise enough to accept any version
that looks reasonably close, because the worst thing that can happen
is a connection failure, which isn't much worse than what you'd get if
you straightly reject the connection attempt after seeing the version
number: either way, this would be a connection failure, but servers
that are tolerant about the version number also may actually see the
connection succeed using the negotiated version number (based on the
client hello version number and the server's capabilities).

Bodo


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