> 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$
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
