Re: [TLS] Simpler backward compatibility rules for 0-RTT

[David Benjamin <[e-mail]>]

On Tue, Jun 21, 2016 at 8:45 PM Martin Thomson <[e-mail]>
wrote:

> On 22 June 2016 at 10:30, Bill Frantz <[e-mail]> wrote:
> > Well, it seems like a browser could try TLS 1.3 without 0-RTT first.
> >
> > If it connects with 1.3 non-0-RTT, then it could mark the host as not
> > supporting 0-RTT for a day or so and after that time retry to see if the
> > host has been fixed.
>
> Yes, that is an option.  Harder to manage, but certainly possible and
> (overall) preferable to falling back to 1.2.
>

Right, that (minus the statefulness because I don't care for adding state
here) was exactly my intent with the specification text. Don't change the
ClientHello version and only retry with the 0-RTT data dropped. It
explicitly says "It is NOT RECOMMENDED to retry the connection in response
to a more generic error or advertise lower versions of TLS."

The version fallback is also inevitable (unless the version negotiation is
moved elsewhere), but at least we can separate the two and someday retire
the version fallback half.

(Also, it's unlikely, but one could also imagine that the retry switches
back to hitting a 1.3-capable server. Then changing the ClientHello version
will trip fallback detection and the connection will fail again. Whereas
retrying with only 0-RTT off is a handshake that will work against 1.2 and
1.3 servers alike.)

I don't care much about the exact distribution of MAY/SHOULD/MUST, if
that's all we disagree on. If we both agree that browsers will have to
fallback, I want the mechanism written down somewhere. Because it's not
obvious that this fallback may be triggered without a version downgrade and
without a broad trigger, both of which have been problems with the past
fallbacks. (The version downgrade has clear security implications and a
broad trigger means debugging harder and, worse, it hides bugs. I've seen
many cases of server software shipping new code that flat-out doesn't work
but fallbacks are so easy to trigger that no one noticed.)

Note that, since TLS stacks typically are not in charge of creating
sockets, the implementation is the same with or without the fallback. The
TLS stack needs to return a very specific error code (<= 1.2 ServerHello in
response to 0-RTT ClientHello) and higher-level logic can condition on it
as it pleases.

David