Re: [TLS] Justification for "Ugly Dirty Hack"

[Stefan Santesson <stefan at aaa-sec.com>]

Michael,

I find your arguments convincing.
This seems to me as a more generic and reasonable approach than a special
server certificate.

/Stefan


On 09-11-19 6:08 PM, "Michael D'Errico" <mike-list at pobox.com> wrote:

> 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
> _______________________________________________
> TLS mailing list
> TLS at ietf.org
> https://www.ietf.org/mailman/listinfo/tls