On Tue, Jan 26, 2016 at 9:11 PM Eric Rescorla <e...@rtfm.com> wrote: > 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. >
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. > 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. > 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.) > 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. > 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
