Re: [TLS] Open issue: Record Version Numbers

[Bodo Moeller <bmoeller@xxxxxxx>]

On Thu, Oct 19, 2006 at 06:44:21PM +0200, Martin Rex wrote:
> 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.

TLS 1.0 vs. SSL 3.0 is different than X.509v3 vs. X509v1 because it is
interactive: Faced with {3,1} records, a server that picks the SSL 3.0
protocol allows the client, in turn, to give the "You can't say we
never tried / ain't it time we said goodbye" fatal alert.  Oops,
sorry, wrong song, make that "protocol_version".

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


> 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

Absolutely, but protocol versions that the client would agree to use
make some sense for the record version number field.

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

Agreed.  It just doesn't work the other way around, in practice: an
SSL 3.0 handshake may be possible even though the client did not
mention {3,0} anywhere.

Bodo


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