On Jun 21, 2016 5:25 PM, "Martin Thomson" <martin.thom...@gmail.com> wrote: > > 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.
Isn't 0-RTT refusable? Why not treat 1.2 negotiation as a refusal? > > 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
