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
