[TLS] Justification for "Ugly Dirty Hack"
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[TLS] Justification for "Ugly Dirty Hack"



Marsh Ray wrote:
Stefan Santesson wrote:
What I don't understand is the rationale for providing two solutions, when
one solution could work for all cases.

TLS can support a nice, clean, efficient solution going forward.

SSLv3 needs an ugly dirty hack, no way around it.

This appears to be the opposition to a solution that does not use
extensions.  That it is an "ugly dirty hack."  Here is how I think
about it:

We are in fact creating new versions of the protocol.  But not in
the sense that the existing version numbering scheme requires, i.e.
a strict linear progression from one version to the next.

We currently have 4 versions: SSLv3, TLS1.0, TLS1.1, TLS1.2.

We are in a sense creating 4 new parallel versions: SSLv3p, TLS1.0p,
TLS1.1p, and TLS1.2p (p meaning patched).

These four new versions sort of interleave into the list we already
have, thus we can't do what would normally be done to select which
version the client wants.  The extension-less approach Martin is
writing up has the client include a "magic" cipher suite in its
hello message to let the server know it is patched and can therefore
negotiate one of the new "p" versions.

If the server is unpatched, it will ignore the magic cipher suite
and continue as normal.  But if it is patched, then there needs to
be an unambiguous way to signal that it has selected a "p" version.
Using the server version in the ServerHello is a natural place to
put that.

My suggestion is to set the upper bit of the minor version field.
This provides a clear and unmistakable signal to the client, and is
completely contained within the 0x03 major version number space.  Is
it a "hack", yeah, but it's entirely reasonable.

Repurposing the Certificate message seems like WAYYYY more of a hack
than this!

This is also entirely forward-compatible.  The next published version
of TLS would be "TLS 4.0" {0x04,0x00}, which is greater than any of
the existing versions and also the "p" versions if the minor version
signals them.

Mike

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.