The stateless technique certainly doesn’t solve all issues with replay. Neither do the other techniques, unless a fairly unrealistic (imo, in most use cases) retry strategy is used. But the stateless technique is definitely an improvement over no anti-replay mechanism at all (for instance it reduces the possible number of rounds of a cache probing attack, assuming the cache TTL > replay window). Which mechanisms to use, and whether to enable 0-RTT in the first place (or PSK mode at all), should be decided considering the tradeoff between security/performance/implementation constraints, etc. In the case of DNS, most DNS security protocols (dnssec, etc.) do allow this kind of replay so I think it is a pretty reasonable tradeoff to consider.
Additionally, I think the stateless technique is quite useful as a defense-in-depth mechanism. I highly doubt all deployments will end up correctly implementing a thorough anti-replay mechanism (whether accidentally or willfully). The stateless method is very cheap, and can be implemented entirely within a TLS library even in a distributed setup, only requiring access to an accurate clock. I’d much rather deployments without a robust and correct anti-replay mechanism break down to allowing replay over a number of seconds, rather than days (or longer). Kyle From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Colm MacCárthaigh Sent: Sunday, May 21, 2017 10:29 PM To: Eric Rescorla <e...@rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] Security review of TLS1.3 0-RTT On Sun, May 21, 2017 at 3:47 PM, Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>> wrote: - Clients MUST NOT use the same ticket multiple times for 0-RTT. I don't understand the purpose of this requirement. As you note below, servers are ultimately responsible for enforcing it, and it's not clear to me why clients obeying it makes life easier for the server. I think clients should duplicate them sometimes, just to keep servers on their toes ;-) this is what we talked about maybe being a grease thing .. if at all. - Servers MUST NOT accept the same ticket with the same binder multiple times for 0-RTT (if any part of ClientHello covered by binder is different, one can assume binders are different). This holds even across servers (i.e., if server1 accepts 0-RTT with ticket X and binder Y, then server2 can not accept 0-RTT with ticket X and binder Y). I assume that what you have in mind here is that the server would know which tickets it was authoritative for anti-replay and would simply reject 0-RTT if it wasn't authoritative? This seems like it would significantly cut down on mass replays, though it would of course still make application-level replay a problem. I'm happy to write this up as part of the first two techniques. I'd be interested in hearing from others in the WG what they think about: 1. Requiring it. 2. Whether they still want to retain the stateless technique. I'm for requiring it, and for removing the stateless technique ... because it prevents the side-channel and DOS attacks and those seem like the most serious ones (and also, the new ones). So far each case where we've thought "Actually stateless might be ok in this case" ... like the example of DNS ... turns out not to be safe when examined more closely (in DNSes case it would compromise privacy because caches could be probed). -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
