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

[Martin Rex <[e-mail]>]

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.  

The decision for the server would be easy, since it knows both protocol
version values (the ClientHello.client_version and his own max. supported
value) after processing ClientHello.  The decision for the client is
more difficult on the initial connect, when it doesn't know yet
whether the server will understand it, and this problem remains
on the renegotiation handshake, where an MitM attacker might proxy
the renegotiation handshake into an initial or renegotiation handshake
of an older server.

One could define my draft-mrex-tls-secure-renegotiation-03 to become
standard with TLSv1.3 and have it grow out of the installed base
naturally, because it changes the handshake message hash, and
prevents you from proxying a new (both initial and renegotiation) handshake
from proxying into handshakes of old servers.

TLS extension RI, on the other hand, does _not_ change the handshake
message hash, so you will have to keep that band-aid around for as long
as you _allow_ interop with TLSv1.2 or below, no matter what TLS WG
defines and implements in newer protocol versions.  Therefore
TLS extension RI is tomorrows cruft.


-Martin