Re: [TLS] One approach to rollback protection

[Matt McCutchen <[e-mail]>]

On Mon, 2011-09-26 at 18:19 -0700, Eric Rescorla wrote:
> On Mon, Sep 26, 2011 at 5:56 PM, Adam Langley <[e-mail]> wrote:
> > 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.

You've already indicated your willingness to take hacks for better
functionality.

> 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?
> 
> I see your point about trying sequentially, but I don't think the
> situation is that
> dire. It's probably reasonable to offer TLS 1.1 or 1.2 and assume that
> TLS 1.1/1.2
> stacks do TLS version negotiation properly. If that fails, fall back
> aggressively
> to SSLv3 or TLS 1.0 with nothing offensive like extensions.
> 
> Or am I missing something?

To clarify Adam's response: there are servers that tolerate TLS 1.0 +
extensions but not TLS 1.2, and clients would like to use TLS 1.0
against such servers.  They can achieve this on a first connection with
TLS 1.0 version + extensions + TLS 1.2 SCSV.  Without Adam's proposed
behavior, clients would need two stages of fallback in order to both use
TLS 1.0 with "semitolerant" servers and successfully connect to
completely intolerant servers.

-- 
Matt