I've added this option to my PR. I've also weakened the deployment requirement to a SHOULD in light of that. I'll learn to live with the bad taste that leaves :)
On 22 June 2016 at 12:31, David Benjamin <david...@chromium.org> wrote: > On Tue, Jun 21, 2016 at 8:45 PM Martin Thomson <martin.thom...@gmail.com> > wrote: >> >> On 22 June 2016 at 10:30, Bill Frantz <fra...@pwpconsult.com> 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
