On Sun, Jun 11, 2017 at 04:18:03PM +0100, Eric Rescorla wrote: > Hi folks, > > We've had a phenomenal amount of discussion around 0-RTT anti-replay, > and based on my recent summary e-mails I think we generally agree > about the technical facts, so it's time to finalize the PR and land it > in the specification. > > > Here's what I propose to do: > > - Describe the attacks that Colm described.
That was mainly five attacks, right? - 0-RTT without stateful anti-replay allows for very high number of replays, breaking rate limiting systems, even high-performance ones, resulting in an opening for DDoS attacks. - 0-RTT without stateful anti-replay allows for very high number of replays, allowing exploiting timing side channels for information leakage. Very few if any applications are engineered to mitigate or eliminate such side channels. - 0-RTT without global anti-replay allows leaking informtation from the 0-RTT data via cache timing attacks. HTTP GET URLs sent to CDNs are especially vulernable. - 0-RTT without global anti-replay allows non-idempotent actions contained in 0-RTT data to be repeated potentially lots of times. Abuse of HTTP GET for non-idempotent actions is fairly common. - 0-RTT allows easily reordering request with retransmission from the client. This can lead to various unexpected application behavior if possibilty of such reordering is not taken into account. "Eventially consistent" datastores are especially vulernable. > - Distinguish between replay and retransmission > > - Mandate (SHOULD-level) that servers do some sort of bounded > (at-most-N times) anti-replay mechanism and emphasize that > implementations that forbid replays entirely (only allowing > retransmission) are superior. I don't remember seeing any scheme that looks feasible to implement, and that could limit amount replays but not to one per "server". (Of course, definition of "server" might sometimes be tricky, e.g. 8 "servers" all running in the same virtual machine. Also, I think SHOULD is bit questionable when not following it is almost certain to lead to severe problems. > - Describe the stateless mechanism as a recommended behavior but not > as a substitute for the other mechanisms. As Martin Thomson has > pointed out, it's a nice pre-filter for either of these other > mechanisms. Basically, the strike register is unimplementatble without bounding the replay window first in time. But I don't think that should be represented as a stateless mechanism, merely as a way of limiting the resources used by the strike register. > - Clarify the behavior you need to get PFS. > > - Require (MUST) that clients only send and servers only accept "safe" > requests in 0-RTT, but allow implementations to determine what is > safe. Also: - Note that 0-RTT exporters are not safe for authentication unless the server does global anti-replay on 0-RTT. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
