Re: [TLS] Black hole was Re: Analysis of Interop scenarios TLS

[Martin Rex <[e-mail]>]

[e-mail] wrote:
> 
> Martin Rex wrote:
> > tom.petch wrote:
> > >
> > > 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.
> > 
> > In theory, you are correct.
> > 
> > This would, however, require us to effectively standarize the secure
> > TLS renegotiation for TLSv1.3 (or some specific TLS version in the
> > future) ahead of time.
> 
> I don't think this is what Tom was proposing. I understood his
> proposal to be something like
> 
>   if negotiated_version <= 1.2 then:
>      if (CH has MSCV) or (CH has RI) or (CH.proposed_version>1.2):
>          client_supports_secure_renegotiation = True
>          include RI in ServerHello
>      else:
>          client_supports_secure_renegotiation = False
>   else:
>      # do what the future spec says -- we don't know yet 
>    
> Or in other words: including a version >1.2 in ClientHello would mean
> the same thing as MSCV or empty RI _when_ the negotiated version is
> <=1.2. (But we wouldn't have to specify the behavior for negotiated
> version >=1.3 at this time.)
> 
> I agree with Tom that if we want to drop MCSV and RI from the
> ClientHello some day, we would need to specify this behavior now.

That would only help to drop the signaling on the initial ClientHello,
but for the renegotiation ClientHello, the TLS extension RI band-aid
will going to be with us for more than 20 years (considering that
SSLv3 is still around after 14 years, and >90% of the installed
base is at TLSv1.0 (close to 100% of the servers) today, almost
10 years after TLSv1.0.

MCSV from draft-mrex-tls-secure-renegotiation-03 could start
disappearing from _ALL_ ClientHellos with the deployment of
TLSv1.3 capable Clients.


>
> But today it would be just more code (and unused code) on the server
> + an extra test case or two.... so there are both pros and cons.

Since such an option can not be covered in "regular" interop testing
at the moment, I tend to agree that it is not worth trying, given
the (lack of) interoperability track record of untested TLS protocol
features.

-Martin