On Mon, Mar 28, 2016 at 3:49 PM, Ryan Hamilton <r...@google.com> wrote:
> > On Mon, Mar 28, 2016 at 3:06 PM, Eric Rescorla <e...@rtfm.com> wrote: > >> Yes, I believe that this is what people want. >> >> On Mon, Mar 28, 2016 at 2:47 PM, Andrei Popov <andrei.po...@microsoft.com >> > wrote: >> >>> Not sending cookies/authz headers in 0-RTT would solve a part of the >>> problem, but will browser vendors go for that? I could be wrong, but there >>> seems to be considerable interest in 0-RTT Token Binding…. so folks must be >>> planning on sending tokensJ. >>> >> > We (Chrome) definitely want this (sending cookies in 0-RTT requests), and > are doing this today with QUIC (which we can't wait to TLS 1.3-ify). > Let's leave aside all of the parts about resumption tokens for a minute. How big adeal would it be if the early data were like the hints I outlined? Let's say a request pattern looked something like; [ replayable_hint data ] GET /foo/bar/1234 HTTP/1.1 Host: www.example.com Cookie: somedata [ application_data ] GET /foo/bar/1234 HTTP/1.1 Host: www.example.com Cookie: somedata ... Obviously this is trivial for clients to generate and send. On the server side; the server could treat the hint as a signal to start rendering "/foo/bar/1234". Obviously the request and the headers are more or less duplicated here; and that uses some bandwidth, but it seems like a pretty trivial amount. The server can reply with its rendering at the same point as the existing 0-RTT proposal; it needn't even read the duplicate request(s) in the application data section. The benefit is that it makes a lot of idempodence issues go away; if the application protocol has to reason about the types of data explicitly, we can be less worried about the potential impact on the many other kinds of protocol that are layered on top of TLS. Then next; and slightly crazier - what if the browser were to very occasionally connect and send only the hint, and the server just had to deal with it. How big a deal would that be? -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
