Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh <[e-mail]>]

On Wed, May 3, 2017 at 3:56 PM, Martin Thomson <[e-mail]>
wrote:

> On 3 May 2017 at 22:45, Colm MacCárthaigh <[e-mail]> 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