Re: [TLS] One approach to rollback protection

[Martin Rex <[e-mail]>]

Adam Langley wrote:
> 
> On Mon, Sep 26, 2011 at 7:44 PM, Eric Rescorla <[e-mail]> wrote:
> > I've taken an initial crack at a draft for this:
> > http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt
> 
> In Table 1 you list TLS 1.1 twice.

2nd column in EKRs draft in front of [RFC5246]? probably simple typo.

And while in theory I do not see a need for a SSLv3 SCSV in EKRs
proposal, it would allow testing the processing of this SCSV
even before implementing TLSv1.2 -- because to test with some
amount of certainty you need your code to support at least
two different versions.


> 
> It has been suggested by Yngve that the existing SSLv3, renego SCSV be
> used to indicate TLS 1.0 support. That's something that I suspect we
> will try.

I'm confused.  SSLv3-only servers (or TLS Servers limited to SSLv3 for
whatever administrative reason) are explicitly allowed to support
TLS renegotiation!

If your client creates and persists longs lists of server properties
so that it may connect in the future without having to go through
a TLS handshake failure and app-level reconnect fallback, then
this may be of help.

The idea behind doing TLS version proposal through a TLS cipher suite
to allow simple TLS clients, that neither persist server feature
characteristics nor contain a reconnect fallback, to succeed
the TLS handshake and use TLSv1.1 without having to worry about
handshake failures from version-intolerant Servers (independent
of whether they choke on ClientHello.client_version > TLSv1.0
or whether they do an incorrect RSA premaster secret client_version check.


> 
> > 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.


Correct, this requirement in EKRs proposal is quite counter-productive
to the problem and needs to be removed.

I would actually prefer not to see any "MUST abort" in that document...


> 
> 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.

Correct.  The ClientHello.client_version = { 0x03, 0x01 } is sent
to keep the potentially version intolerant installed base working,
the TLS 1.1 or TLS 1.2 SCSV is sent to negotiate 1.1 or 1.2 with
peers supporting this scheme in spite of the conservative
ClientHello.client_version.

-Martin