On Wed, May 3, 2017 at 3:56 PM, Martin Thomson <[email protected]> wrote:
> On 3 May 2017 at 22:45, Colm MacCárthaigh <[email protected]> wrote: > > This is easy to say; the TLS layer is the right place. It is not > practical > > for applications to defend themselves, especially from timing attacks. > > If you care about these attacks as much as it appears, then you can't > reasonably take this position. An analogy may help here. TLS has always offered anti-replay, it is one of our core security guarantees, and the assumption that it is there is subtly baked in to many applications. Suppose we wanted to remove a different security guarantee: integrity protection/tamper-proofing. Suppose we decided to offer a fast "No MAC" mode for streamed uploads, it is faster, more stream-y (no need to wait for each record to be complete), and TLS is really mostly about secrecy. But to be "safe" we decide that it's only on optionally and sometimes, and we always have to tell the application which data may have been tampered with. The application can use its own MACing, or FECing, or whatever, and really it should have been doing this from the days of plaintext HTTP, right!? It's all the application's responsibility - we say, they can deal with it [*] Except MACing is hard, and they run in to Lucky13 all over again, or just use MD5 because they don't know any better, and so on. Or worst of all: a middle box decides to enable it on the front-end, with no knowledge to the backend about what's happening. In my view, this arrangement would plainly be crazy. We wouldn't consider it. Instead, we provide protection for them using layering principles, and TLS provides protections that TLS experts are good at. And yet we do consider all of this for replay. I think it's because collectively we haven't seen just how hard a problem idempotency and application-level side-effects are and we are less familiar with the risks. In the review, I've included 5 real attacks to illustrate that problems are real. Several of them I can't see how to mitigate them at application level, and I've been checking with experts on distributed systems. How would you mitigate the throttling problem (attack 3) or the timing problem (attack 4) on say a JVM object cache? > We've historically done a lot to > secure applications at a single point, and we're almost at the end of > what we can reasonably do for them at this layer. We need to think > more hollistically and acknowledge that applications need to take some > responsibility for their own security. > No we don't. Servers can prevent replay. -- Colm
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
