On Tue, Jan 26, 2016 at 6:02 PM, David Benjamin <david...@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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
