Re: [TLS] Version (in)tolerance

[Marsh Ray <[e-mail]>]

On 6/17/2010 7:26 AM, Peter Gutmann wrote:
> Marsh Ray <[e-mail]> writes:
> 
>> * If an optional protocol feature has no implementations that are available
>> and widely used for testing, it can be relied on not to work.
> 
> And that's exactly why I reject major versions other than 3, I have no idea
> what version 4 will be or require, and I also have no way of checking that I'm
> not subject to some sort of rollback attack or who knows what if I include
> handling for a 4.x version.

Your implementation is saying to the remote endpoint: "Even though there
is a highest protocol version which we both support, and even though I
am willing to talk that version in general, I am not willing to
handshake you at all because you said you also supported some version
higher than that."

Again, nowhere in RFC 5246 does it say that a ClientHello
client_version.major other than 0x03 will equate to a "4.x" TLS version
or give any significance to 4 (other than that it is greater than 3).

Instead, it says:
> If a TLS server receives a ClientHello containing a version number
> greater than the highest version supported by the server, it MUST
> reply according to the highest version supported by the server.



> So in order to force users to get a version that
> deals with whatever security catastrophe 4.x is meant to address, I want to
> make sure that they're forced to upgrade.

I guess I see some kind of Kafakaesque logic in the idea of an paranoid
endpoint gaining security by refusing to interoperate with newer
implementations.

But why stop there? It would be even more effective for the compromised
implementation to delete itself from disk once a higher protocol version
is observed on the network. That would also be an elegant solution to
the problem of having to work around all those intolerant servers in the
fix for catastrophic break.

It should probably also trip fail-safe whenever a client proposes a
ciphersuite it hasn't seen before. Could be an indication that the one
it otherwise would have chosen has a major weakness. Don't forget
unexpected compression methods and unknown extensions either! After all,
the presence of the new ciphersuite value and/or RI extension is, in
fact, an indication that the original protocol had a major flaw.

Alternatively, you could log a warning message or find some other means
to get the point across.

> This was a problem with PGP 2.x, there was never any strong reason for people
> to upgrade, and it took forever to get people to move off it (some are still
> using it).  Someone (from memory it was Jon Callas) has complained that PGP
> 2.x needed some fatal flaw found in it to force people to finally move to
> OpenPGP.  So having a fall-over-and-die trigger can be a good thing, not a
> flaw.

Cause enough pain for your users and I guess they'll switch to something
else. Did you consider that it also causes pain for those trying to fix
and extend the protocol using the methods defined in advance for that
purpose?

When updating the protocol we heard repeatedly that avoiding interop
problems with the installed base must be the number one requirement.
With the renegotiation bug people insisted it would take forever to get
everyone patched. But if the patch did not interop, no one would patch
at all.

Look back at the mailing list. We knew of a single server on the
internet that went into a slow fail condition when it received extension
data on a client hello. That was one server was taken seriously as a
significant factor in the adoption of the ugly kludge workaround for
intolerant.

So the effect of that "fall-over-and-die" approach is going to be far
more of a hindrance to the adoption of a fix to the protocol than it is
likely to protect anyone using such an implementation.

If the protocol really turns out to be broken in such a systemic way
that "4.x" is only solution, there's a good chance the attacker will be
able to undetectably modify the version number your endpoint sees anyway.

> In any case though since no-one has any idea what 4.x will be, or why we'd
> need to move to it, or whether it will ever appear, this is all just
> speculation, it's like arguing over what clothes work best for interstellar
> travel.

Hmm, I don't really think so. We're talking about specific behavior
mandated by the current RFCs and principles which have numerous examples
of actual use. It's similar to the warnings-as-errors discussion we were
having earlier.

Oh and it'll definitely be a silver lame' catsuit for me.   :-)

- Marsh