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

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

On Wed, May 31, 2017 at 12:49 PM, Victor Vasiliev <[e-mail]>
wrote:

> I think I am not getting my key point across here clearly.  I am not
> arguing
> that they are inconvenient, I am arguing that the guarantee you are trying
> to
> provide is impossible.
>
> I wholeheartedly agree that if it is possible to provide guarantee B (zero
> replays), we really should provide it.  The problem is, we cannot.  Since
> 0-RTT
> is by its very design declinable, there will be always a possibility for at
> least one retry.
>

This is the part we agree on; but as I've said before, the kinds of attacks
enabled by these kinds of client-initiated retries, and by
attacker-initiated replays are fundamentally different.


> Once you concede you can have at least one replay, the difference between
> one
> replay and N replays (for all N > 0) is not that large, which is why I
> refer to
> this as "nebulous bound" (guarantee C).
>

There's a very big difference and it leads to real-world attacks. With many
replays, all sorts of side-channel analyses become possible, and I've
provided examples. It's particularly nasty that the replays can be
out-of-bound and to arbitrary nodes of the attacker's choosing, which makes
the attacks even more effective.


> Your applications already have to
> contend with replays, it's now just the matter of preventing side-channel
> amplification.
>

Yes; applications using 0-RTT do have to make themselves retry-tolerant,
 as they already must in many scenarios (e.g. a browser driven
application).  What concerns me most here is that people are clearly being
confused by the TLS 1.3 draft into mis-understanding how this interacts
with 0-RTT. For example the X-header trick, to derive an idempotency token
from the binder, that one experimental deployment innovated doesn't
actually work because it doesn't protect against the DKG attack. We're
walking into rakes here.

So, in other words, since we're now just bargaining about the value of N,
> operational concerns are a fair game.
>

They're still not fair game imo, because there's a big difference between
permitting exactly
one duplicate, associated with a client-driven retry, and permitting huge
volumes of replays. They enable different kinds of attacks.

I keep forgetting about forward secrecy in all of this, but it's worth
noting that your argument for globally resumable sessions also implies that
we shouldn't really shoot for  FS for some of the most critical user data.
I also find that bizarre.

To clarify, I am not suggesting that two streams would help.  I completely
> agree with you that two streams is not going to mitigate the DKG attack or
> others.  What I meant is that 0-RTT inherently has slightly different
> properties from 1-RTT and must be used with that in mind.  Specifically, I
> meant that it will not be enabled for applications by default, and HTTP
> clients
> would only allow it for methods that RFC 7231 defines as safe.
>

Well in the real world, I think it'll be pervasive, and I even think it
/should/ be. We should make 0-RTT that safe and remove the sharp edges.

>
> I do not believe that this to be the case.  The DKG attack is an attack
> that allows
> for a replay.
>

It's not. It permits a retry. The difference here is that the client is in
full control. It can decide to delay, to change a unique request ID, or
even not to retry at all. But the legitimate client generated the first
attempt, it can be signaled that it wasn't accepted, and then it generates
the second attempt. If it really really needs to it can even reason about
the complicated semantics of the earlier request being possibly
re-submitted later by an attacker.

Replays are different though; the attacker just literally copies the data
and can resend and resend as desired. As I've shown; this breaks real-world
things like authenticated throttling systems, and leads to side-channel and
cache analysis; where only very rarely is one attempt sufficient to
exploit.


> There is an enormous difference between a protocol that does not
> allow replays and the protocol that allows one.  For many applications, it
> only
> takes one replay for things to go terribly wrong.
>
>
>> The only place that the DKG attack can be mitigated is at application
>> layer.
>>
>
> Indeed.
>
>
>> The TLS APIs and different streams are pointless here.
>>
>
> I agree that different streams are pointless.  The only ways APIs can help
> is
> to not send replay-sensitive requests via 0-RTT, and to not accept those
> requests until peer liveness is confirmed.
>

This puts a massive smile on my face :)

>
> Indeed, but I am not suggesting we ignore those attacks.  The way I see
> this is
> that, originally when we did 0-RTT in QUIC, we had strike registers which
> are
> approximately what you are advocating.
>

Well I'd really advocate for single-use caches, because I think Forward
Secrecy is important :)


> We thought this provided property B
> (at-most-once semantics for 0-RTT), but at the IETF, people discovered the
> DKG
> attack.  Strike registers do not provide B and in fact B is impossible to
> provide at the TLS layer.  Thus TLS 1.3 went towards A (no replay
> protection at
> all for 0-RTT), as it's simpler and we didn't have B anyway.
>

I think in retrospect this was rash :(


> But, as you describe, this enables some interesting side channels. Now,
> these
> side channels exist even without 0-RTT.  Attackers already can measure
> response
> times, probe and groom caches, direct traffic, etc.  *But*, with unlimited
> 0-RTT replay, the attacker can repeat the experiment unboundedly and
> amplify
> the side channel.
>

Exactly :) but also ... what about the attack on the throttling
infrastructure? or other resource exhaustion? 0-RTT replay seems like a
really big problem here and it seems like the most realistic kind of attack
too; booters and trouble-makers trying to lock each other out of systems.


Thus, A is problematic.  I think we both believe this and both agree then
> that
> the current text is unsatisfactory.  So the question is what to replace it
> with.  Whatever we provide, it should be a clear security guarantee
> between the
> application and TLS (depending on what guarantee we chose, some of your
> other
> attacks may or may not just be invalid uses of TLS).  B is obviously
> preferable, but as it is impossible per DKG, I think we should set the
> contract
> at C (bounded replay protection).  This is a guarantee that is not
> fundamentally impossible and also successfully mitigates your side channel
> amplification attacks.
>

I'm all for bounded replay protection, with the bounds being 1 ;-)

-- 
Colm