On Mon, Jun 12, 2017 at 11:19 AM, Salz, Rich <rs...@akamai.com> wrote:
> I agree with this. Which is why I prefer separate streams for early data, > and some kind of signaling to the content provider that is clear and > unambiguous. I don't know how to do that when, say, the intermediary/CDN > has a persistent connection to the backend... > I've given this some thought, and I think it might be unworkable to have some kind of end-to-end 0-RTT. A simple example is that a CDN might want to make a slightly different request, with extra headers, towards the origin than the request that came in from the browser. For instance, the CDN might add an If-None-Match: or an If-Modified-Since. But those may not fit within the 0-RTT size limit. It gets really complicated across layering boundaries to have the CDN only accept 0-RTT if the origin also does, and if the request towards the origin will also fit, and so on. I think the CDN would have to defer accepting the 0-RTT from the browser until the origin accepted the 0-RTT from the origin; which defeats a lot of the intended speed/throughput benefit. Through this I've come to the conclusion that separate streams create more problems than they solve, and robust replay mitigation is a better answer. -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
