Re: [TLS] Version (in)tolerance

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> On 6/17/2010 1:48 AM, Peter Gutmann wrote:
> > "Brian Smith" <[e-mail]> writes:
> > 
> >> NSS has an explicit check that the first byte of every version 
> >> number is 0x03. I imagine other implementations have a similar 
> >> check.
> > 
> > I do that too, and it's quite deliberate, we've been using 3.x for 
> > 15-odd years and there's no sign, even with major incompatible 
> > protocol revisions, that we're going to 4.x at any point.
> 
> But this is the part of the handshake where the protocol version hasn't
> actually been agreed on yet. Some future TLS may, in fact, be a big
> protocol change but a server is still wrong to refuse to interoperate on
> the basis that the client merely proposed a higher protocol version.
> 
> 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.)


> 
> > Any change to 4.x is therefore going to either never happen or will 
> > be something so major, probably a complete break of the entire 
> > protocol, that I want to force users to upgrade to a completely new 
> > release.
> 
> A. We don't know anything about future protocols yet, other than that
> the client hello message will probably try to maintain compatibility
> back to 1.0 and IANA-assigned identifiers won't collide. 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.

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


-Martin