Re: [TLS] The case for a single stream of data

["Salz, Rich" <[e-mail]>]

> It's actually impossible because a 0RTT request may be retried as a 1RTT request and there's no way to correlate the two. So when the 1RTT request shows up, we can't go "This might be a repeat" - for example the X- header trick doesn't work in this case. It's subtle, which makes it even more likely to trip on it. 

That also assumes that the 0RTT data will be a completely self-contained request.  I share the concern that Kyle and others have pointed out, that a single request will span the boundaries.

> I think the only approach that actually rigorously works is the client-side one

Attackers will not use well-behaved clients; does your approach still work?

>The second problem is that middle-boxes can break any signaling. For example a CDN or TLS accelerator may enable 0-RTT towards the back-end origin without enabling it to the original client. In this model, the client has *no* way to reason about retries or replay.

A CDN is not a middlebox.  As far as the client is concerned a CDN *is* the origin.  The agreement in-place between the CDN and the origin is out of scope here.  A TLS accelerator, which is a tool to help an origin with its *local* performance, or other lower-layer (in the L3 L5 etc sense) assist is within scope.  Does that make sense?

> That's really very broken and a serious violation of the transport layer contract.

Only if you believe CDN is a middlebox.  The transport layer contract is overridden by legal contracts or EULA :)

	/r$