Re: [TLS] One approach to rollback protection

[Martin Rex <[e-mail]>]

Eric Rescorla wrote:
> > 
> > > If the SCSV value is present and is not equal to
> > > ClientHello.client_version, then the server MUST terminate
> > > the handshake with a fatal "handshake_failure" alert.
> >
> > This doesn't really make the deployment of new TLS versions that much
> > easier. The client would still have to try 1.2, 1.1, 1.0 etc. What
> > would be helpful is if the server, seeing a TLS 1.2 SCSV, treated the
> > client as if it has advertised 1.2.
> 
> That's certainly a possibility, but now we're actually substituting
> the negotiation mechanism with one based on smuggling it in ciphersuites,
> which is pretty gross.

Now I'm somewhat puzzled.

Was your motivation to propose this only to ensure that a TLSv1.0,
SSLv3 or SSL Version 2 CLIENT-HELLO results in a fatal handshake failure
when both peers support higher than TLSv1.0?

I'm strongly opposed to that idea.

What I'm looking for is a protocol enhancements that will **IMPROVE**
TLS interop by having more TLS handshakes succeed.


>
> Moreover, unless I'm missing something, this leaves the client unable to offer
> extensions (since they often cause breakage as well) unless it has fallback,
> at which point why not use fallback for version logic as well?

No problem, TLSv1.1 and TLSv1.2 work just fine without extensions.
And if that is really an issue, an alternative would be to perform
a renegotiation directly after the handshake succeeded -- with the
added bonus that it incurs no handshake failure -- meaning that
it could be performed entirely within TLS and without involvement
of the calling application.

A handshake failure is a significant problem, since it always requires
the involvement of the application and a new network connection.


-Martin