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

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 <davidben@chromium.org> wrote:
> On Tue, Jun 21, 2016 at 1:54 PM Ilari Liusvaara <ilariliusvaara@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.thomson@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
>