Subject: [TLS] Backwards-compatibility of 0-RTT data

From: David Benjamin <[email-masked]>
Date: Wed, 27 Jan 2016 02:02:39 +0000

Instead of putting 0-RTT data in a ClientHello extension, the current draft
has the client send extra records in the first flight, right? (I see an
early_data extension, but it seems only be an indicator. There's also
mention of requiring trial decryption which only makes sense if it were
appended.) Was there a reason not to put it into an extension? It's uglier,
but the current scheme has compatibility risks and may force clients into a
fallback dance.

Although a TLS 1.3 client won't make 0-RTT handshakes to a service until
it's managed to speak TLS 1.3 to it once, services aren't made of one
machine. Many services span multiple machines, changes are deployed
incrementally, etc. Even single-machine services may need to roll back a
change. This kind of statefulness means that one cannot enable 0-RTT on
*any* machine until *all* machines in the fleet have enabled TLS 1.3. And
TLS 1.3 may not be rolled back once 0-RTT is enabled (at least not until
all server configs have expired).

I would not expect all deployments to get this right. Large companies with
TLS experts might, but most people will idly take updates from their
operating system with (hopefully!) TLS 1.3 and 0-RTT enabled by default.
They won't realize fleets must "set" at TLS 1.3 without 0-RTT before
enabling TLS 1.3 with 0-RTT.

This is the same flavor of problems in session resumption that motivated
https://github.com/tlswg/tls13-spec/issues/136. That bug wasn't
hypothetical. At the time I filed that issue, https://www.debian.org was
two wildly different servers. One spoke up to TLS 1.0 and the other up to
TLS 1.2. OpenSSL on the client has some bugs around resumption which gives
similar version stickiness effects. Until I reworked the version
negotiation code, Chrome + BoringSSL would fail to connect sometimes.

Having the 0-RTT data delimited in the ClientHello should hopefully also
avoid the trial decryption step on 0-RTT miss which seems kind of silly.

David

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Jan 2016 18:11:08 -0800

On Tue, Jan 26, 2016 at 6:02 PM, David Benjamin <[email-masked]>
wrote:

> Instead of putting 0-RTT data in a ClientHello extension, the current
> draft has the client send extra records in the first flight, right? (I see
> an early_data extension, but it seems only be an indicator. There's also

Yes, it means you can't stream 0-RTT data because you have to know it all in
advance. We had a number of requests for this.

> all server configs have expired).

I don't think this is entirely true: Web clients already fall back on hard
failures.
But yes, thats the general design.

> operating system with (hopefully!) TLS 1.3 and 0-RTT enabled by default.

Well, I think we're generally encouraging people to have to explicitly
enable 0-RTT.

-Ekr

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Jan 2016 13:13:26 +1100

> Well, I think we're generally encouraging people to have to explicitly

I think that the key point was that you would have to explicitly
enable 0-RTT AND that also meant a commitment not to choke on 0-RTT
data for at least as long as your 0-RTT configurations were valid.

---

From: David Benjamin <[email-masked]>
Date: Wed, 27 Jan 2016 03:30:29 +0000

> advance. We had a number of requests for this.

Hrm, that's fair. I don't see any way to have both that and avoid this
statefulness problem, so I guess we have to pick one. And then the other
will want some scary warnings in the spec.

> But yes, thats the general design.

We've been trying to get rid of these sorts of fallbacks as they tend to
cause problems. (The version fallback, notably, has not exactly been a
success story...) Though it does sound like I may need a 0-RTT-less
fallback then. (Or at least to explicit invalidate the 0-RTT cache on
connection error.)

> Well, I think we're generally encouraging people to have to explicitly

At the TLS level, of course. But, at the HTTP level, popular HTTP servers
will no doubt enable it for GETs or so. People will be taking updates to
those too.

David