[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] Open issue: Record Version Numbers
Bodo Moeller wrote:
>
> 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.
I totally disagree. An Implementation of SSLv3 knows at best
all PDUs up to and including {3,0}. It does NOT know whether there
are any changes in the {3,1} record protocol, and by design, it
should NOT try to parse records tagged with {3,1}.
Existing patches to SSLv3 only server do not claim to parse the
{3,1} record protocol, they try to parse inappropriately tagged
{3,0} records instead.
Similarly as a simple X.509 certificate that doesn't contain any
X.509v3 attributes ought to be tagged as X.509v1. Implementations
that do otherwise are broken.
The original TLSv1 spec didn't contain a MUST, but rather a SHOULD,
so we ought to retain a SHOULD, and not contort it to a MAY to
cater the installed base of broken TLSv1 server implementations.
The client should use the lowest protocol version it is willing to
negotiate on the record protocol of the client hello, and the
desired protocol version (per default the highest it implements)
in the client protocol version field of the client hello.
Technically, if a client would agree to either SSLv3 or TLSv1.1,
but NOT TLSv1.0, then having a recommendation for sending {3,1}
in the record protocol would be quite weird (I don't want to
discuss whether such a combination makes sense).
Anyway -- a reliable indicator for the server that the client
is going to agree to a SSLv3 handshake is the presence of
{3,0} in the record protocol of the client hello message.
-Martin
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls