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

On Tue, Jan 26, 2016 at 6:02 PM, David Benjamin <davidben@chromium.org>
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
> 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.
>

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.

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 don't think this is entirely true: Web clients already fall back on hard
failures.
But yes, thats the general design.

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.
>

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

-Ekr

> 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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>