Re: [TLS] Version (in)tolerance

[Marsh Ray <[e-mail]>]

On 6/17/2010 9:20 AM, Martin Rex wrote:
> Marsh Ray wrote:
>>
>> For testing purposes, a client which specified a client_version of
>> 0xFFFF should be able to successfully handshake using the highest
>> version the server supports. This works with some implementations today.
> 
> Maybe you want to turn your attention to the DTLS spec
> and reconsider your recommendation:
> 
> http://tools.ietf.org/html/rfc-4347#section-4
>       version
>        The version of the protocol being employed.  This document
>        describes DTLS Version 1.0, which uses the version { 254, 255
>        }.  The version value of 254.255 is the 1's complement of DTLS
>        Version 1.0. This maximal spacing between TLS and DTLS version
>        numbers ensures that records from the two protocols can be
>        easily distinguished.  It should be noted that future on-the-wire
>        version numbers of DTLS are decreasing in value (while the true
>        version number is increasing in value.)

I'm happy to be proven wrong (if get educated in the bargain :-), but I
don't think that's quite it. That section is talking about the record
layer version field, I was talking about the version negotiation in the
Hello messages.

The DTLS ClientHello message appears to be incompatible with a TLS
ClientHello, a new field was added right in the middle. So that record
layer number would be needed to interpret them (assuming it would ever
make sense for them to be in a context together where they could be
confused).

If this record layer version field is, in practice, being overloaded to
work as some sort of protocol identifier it should probably be managed
properly by the IANA. OTOH, maybe this is just a hint for Wireshark.

The TLS RFCs do not cite the DTLS RFC, therefore DTLS is basically
considered different protocol, right? According to the TLS RFCs and
normative references I read, a TLS server MUST have the behavior I
described. That's based on my dim understanding, but surely others know
how to interpret these things better.

>> If, after all,
>> TLS version 1.2 is 0x0303 then who can say what 0x0404 will mean?
> 
> TLS protocol_version numbers work differently.  The version negotiation
> is not capable of dealing with "holes".  So the next version of TLS
> should be using the protocol_version of { 0x03, 0x04 }, no matter how
> much it differs from TLSv1.2 (protocol_version { 0x03, 0x03 }) and
> even if we give it the "marketing name" TLSv2.0, it should use the
> protocol_version { 0x03, 0x04 } on the wire.

So what what we _can_ say about {0x04, 0x04} then is that it is the
257th version after TLSv1.2.

This might support my argument that we shouldn't think of them as
{major, minor} numbers at all, but as a simple unint16. Leave the "x.y"
version numbers to Marketing, unless there's some reason to define the
semantics that way.

> But there is really a design problem in the "common version" negotiation
> of TLS because of the implication that the client supports lower
> protocol version than the one it proposes.

If the server selects his highest version, and that turns out to be
lower than the client's lowest supported version, then they don't have
any version in common and wouldn't be able to successfully handshake anyway.

> If we were to define a substantially different TLSv2.0, and a problem
> would be found that needed fixing, the current versioning precludes
> that a TLSv1.3 is defined _after_ a TLSv2.0.  -- which is why I
> strongly prefer fancy new features to be added through TLS extensions
> rather than a bump of the protocol version -- because it can be
> more easily adopted by implementations and the installed base.

I guess, in theory, the client and/or server could support noncontiguous
ranges of versions (there are three or four of them now after all). If
that ever turns out to be needed, it seems like it could be supported in
a straightforward way with a Hello extension.

- Marsh