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
