On Tue, May 9, 2017 at 9:41 AM, Salz, Rich <rs...@akamai.com> wrote: > > 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. >
True; though I think the partial request case it's ok ... I think it's just orphaned data. The mechanisms that prevent 0-RTT insertion across different connections do seem robust. > > 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? > Yes; it's about signaling to the client that "Your data may or may not have been received". This is an ordinary failure mode for TCP and TLS and something many clients have careful reasoning around. The difference with 0-RTT is now there's a bigger window of time during which that request may get received, but that's it really. If the attacker replays, then it can be received; and the attacker can use any client, but it doesn't change the original well-behaved client's reasoning. >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. No I don't think this works in transactional systems. For example; suppose the client performs an update or write "through" the CDN, and 0-RTT is being used on both sides. In the 0-RTT world, the CDN might be subject to replay between the CDN and the Origin. But as defined, the actual client gets no visibility of that. That breaks careful clients. For example they may get a 500 back and assume that the request failed, without knowing that the request may be replayed any time in the next 10 seconds and therefore succeed. This can all be made workable though; with a careful consideration of how the signaling propagates; that's not in the draft at this time though. > > 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 :) > Of course, but I think this is a predictable security problem. The implications are very subtle and may be exploited by attackers, while people unknowingly enable the behavior. I realize I'm in dark corner cases here; but I think we should approach all of this with the same rigor we treat the TLS state machine and crypto proofs. -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
