On Mon, May 22, 2017 at 10:12 AM, Kyle Nekritz <knekr...@fb.com> wrote:
> 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. > The stateless technique is insecure; plain and simple, and it is far more easily exploited than issues that have caused us to deprecate cipher suites. It should come out. It enables attacks that are materially different from forced retries, such as cache probing and statistical side-channel analysis. > 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). > Today TLS has robust anti-replay; the comparison to "no anti-replay mechanism at all" isn't relevant. > 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. > This same argument could be made for keeping MD5, or RC4. DNSSEC is not concerned with secrecy. TLS is. This exact kind of replay would compromise the secrecy of the data being transported. > Additionally, I think the stateless technique is quite useful as a > defense-in-depth mechanism. > It's tempting because it lowers the costs for implementors, but it's absolutely not secure. I seriously doubt that any application can be made side-channel free in the manner that would be required to preserve secrecy. > I highly doubt all deployments will end up correctly implementing a > thorough anti-replay mechanism (whether accidentally or willfully). > This is why I think we should GREASE this and report (to users) any sites that show any signs of replay tolerance. > 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). > I'd prefer if that were possible too, but it's not possible - it's insecure. -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
