[TLS] Black hole was Re: Analysis of Interop scenarios TLS extension RI w/MCSV

["tom.petch" <[e-mail]>]

----- Original Message -----
From: "Marsh Ray" <[e-mail]>
To: "David-Sarah Hopwood" <[e-mail]>; <[e-mail]>
Sent: Friday, December 11, 2009 5:33 PM
Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV

> David-Sarah Hopwood wrote:
> >
> > Why? What is the point of allowing the client to send an empty extension,
> > when a patched client MUST send the MSCV, and a patched server MUST use
> > *only* the MSCV to determine whether the client is patched? You'd just be
> > adding the option to send an extension that has no defined meaning.
>
> I would like for the decisions we make today to allow the MCSV hack to
> be retired at some point in the future. MCSV represents extra complexity
> that we added as a concession for interoperability with obsolete and
> out-of-spec systems. We all have to make compromises in life and
> protocol design, but it is better to do it in such a way that they
> eventually pass into history rather than build up over time.
>
> Today there are many clients which never interoperate with
> extensions-intolerant servers. If at all possible, these should have the
> option of not sending the MCSV hack from the beginning.

I was going to say that that logic leads me to conclude that we
should not send the empty extension either.  In a future version -
someone suggested 3.7 :-) - the binding of renegotiation to negotiation is
built in to the protocol and so no signalling - no MCSV, no RI, -
nothing extra is needed in ClientHello.

But while any server not supporting that version would fall back to TLS
1.somethingLess (which is the patched protocol we are now developping)
and would signal in whatever way we now decide that is supports the patch,
it would still need to know that this client with a version number it has
never heard of also supports the patch, so the client will have to go
on signalling in perpetuity.  In effect, we are digging ourselves a black
hole.

There is a solution.  We should require, as part of this patch, that upgraded
stacks treat a version number that is greater than some specified value as
also being a signal that the peer is upgraded.  Then we will be able to drop
the MCSV and/or RI as a signal from the '3.7' ClientHello. But we do need
to include this now.

Tom Petch

> - Marsh