To be clear about this, I expect that browsers will do some fairly horrific things in response to this. We will attempt to use 0-RTT, get TLS 1.2 and abort as described.
But then we will do the shameful thing and fall back to 1.2. Plotting out the alternatives, I don't really see a better option. On 22 June 2016 at 04:45, David Benjamin <david...@chromium.org> wrote: > On Tue, Jun 21, 2016 at 1:54 PM Ilari Liusvaara <ilariliusva...@welho.com> > wrote: >> >> On Tue, Jun 21, 2016 at 10:07:17AM -0700, Ryan Hamilton wrote: >> > On Mon, Jun 20, 2016 at 6:15 PM, Martin Thomson >> > <martin.thom...@gmail.com> >> > wrote: >> > >> > > David Benjamin wrote our section on 0-RTT backward compatibility to be >> > > a little bit lenient about server deployment. On consideration, I >> > > think that a simpler set of rules are better: >> > > >> > > 1. If the server advertises support for 0-RTT, then it implies a >> > > commitment to support TLS 1.3 for the duration of that advertisement. >> > > 2. Therefore, if the client attempts 0-RTT, then it should reject a >> > > ServerHello with TLS 1.2 or older. >> > > >> > >> > How does this affect the situation where a server might attempt to >> > deploy >> > TLS 1.3, discover a bug, and need to rollback? Does it just magically >> > work? >> >> AFAIU, if one has 0-RTT-capable dynamic PSKs out there, one can only roll >> back 0-RTT support, but has to wait for all the PSKs to expire beefore >> being able to roll back TLS 1.3. >> >> Of course, the period between deploying TLS 1.3 and deploying 0-RTT >> should test how things work without 0-RTT (but it does not test 0-RTT >> failing, which is _critical_ to work correctly). > > > Right, this is the deployment complexity I was hoping to avoid with the > section. I expect that large companies with TLS experts on staff will be > able to navigate this difficulty. We can deploy TLS 1.3, wait for everything > to stick, and then turn on 0-RTT. > > But smaller and medium-size deployments may simply have a handful of stock > installs of their favorite operating system and server software. People like > things being fast, so either 0-RTT will be on by default on web servers or > people will copy-and-paste config options. It's those deployments which I > don't expect to get this right. > > This isn't a theoretical concern. OpenSSL and very early revisions of > BoringSSL had a bug around session handling with similar effects. If one > established a TLS 1.2 session and then later did a full TLS 1.0 handshake, > even though the TLS 1.2 session was *not* resumed, merely offering it caused > OpenSSL to lock the version. Very early on in switching Chrome from NSS to > BoringSSL, we hit interoperability issues due to this. > https://www.debian.org, at the time, had a heterogeneous deployment of TLS > 1.0 and 1.2. This was rather messy to diagnose. Flaky failures are the > worst. > > I can also imagine this sort of thing happening if users turn antivirus > products with TLS MITMs on and off, or if they have a work machine with a > TLS MITM certificate and enter/leave their networks. (I'm sure no one on > this list, myself included, has any love for this sort of configuration, but > it is reality.) > > David > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
