Re: [TLS] Version (in)tolerance

[Marsh Ray <[e-mail]>]

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.

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

B. What if every protocol implementer and application developer acted
this way? What if they applied predictive numerology on reserved values
and decided to break compatibility in order to "force users to upgrade"?
Big vendors can have legal concerns which discourage that sort of thing
but unfortunately it seems common among smaller ones.

If a significant percentage of client-version-intolerant servers are
allowed to pollute the ecosystem, clients implementing some future TLS
(or TLS-compatible) protocol with a version number encoding other than
0x03xx will experience problems. They will be slowed down by failed
handshakes. Application code will be forced to implement complex
fallback reconnection schemes that are subject to downgrade attacks.

The net effect will be to simply slow the adoption of future protocol
versions and make it more difficult to evolve TLS without compatibility
problems. For example, fixing the renegotiation auth gap would have been
easier if actual servers consistently ignored hello extensions that they
didn't care about.

It may end up that it's just impractical for a client to ever advertise
a version number that doesn't look like 0x03xx. If that is the case,
then there's a wasted byte in the protocol header.

Here are my take-aways (from this and some other experiences):

* Protocols are hard, extensible ones moreso. Even for seemingly simple
stuff like version agreement, the default state seems to be
non-interoperability. This makes it interesting.

* Don't encode a version as separate components unless there are useful
distinctions between each component. In the absence of defined semantics
people will interpret their own.

* If an optional protocol feature has no implementations that are
available and widely used for testing, it can be relied on not to work.

- Marsh