Re: [TLS] Simpler backward compatibility rules for 0-RTT

[David Benjamin <[e-mail]>]

On Tue, Jun 21, 2016 at 1:54 PM Ilari Liusvaara <[e-mail]>
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 <
> [e-mail]>
> > 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