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

[Victor Vasiliev <[e-mail]>]

On Wed, May 31, 2017 at 4:52 PM, Colm MacCárthaigh <[e-mail]>
wrote:
>
> 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.
>

I am not sure I agree with this distinction.  I can accept the difference in
terms of how much attacker can retry -- but we've already agreed that
bounding
that number is a good idea.  I don't see any meaningful distinction in other
regards.

>
>
>> 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.
>

Sure, but this is just an argument for making N small.  Also, retrys can
also
be directed to arbitrary nodes.


>
>> 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).
>

I am glad we agree on that point.


> 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.
>

Of course it doesn't protect against the DKG attack, but nothing at that
layer
actually does.

This sounds like an issue with the current wording of the draft.  As I
mentioned, I believe we should be very clear on what the developers should
and
should not expect from TLS.


> 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.
>
>
Sure, but there's a space between "one" and "huge amount".


> 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.
>

Are you arguing that non-safe requests should be allowed to be sent via
0-RTT?
Because that actually violates reasonable expectations of security
guarantees
for TLS, and I do not believe that is acceptable.


>> 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.
>

That's already not acceptable for a lot of applications -- and by enabling
0-RTT for non-safe HTTP requests, we would be pulling the rug from under
them.

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.
>

Sure, but all of those are either:
 (a) side channel attacks covered by guarantee C, or
 (b) a violation of semantic contract between TLS and the application.


> [snip]
>
>
>> 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.
>

Throttling POST requests is fine -- they shouldn't go over 0-RTT, since they
are not idempotent.  Throttling GET requests in this manner goes at odds
with
RFC 7231:

   Request methods are considered "safe" if their defined semantics are
   essentially read-only; i.e., the client does not request, and does
   not expect, any state change on the origin server as a result of
   applying a safe method to a target resource.  Likewise, reasonable
   use of a safe method is not expected to cause any harm, loss of
   property, or unusual burden on the origin server.

   This definition of safe methods does not prevent an implementation
   from including behavior that is potentially harmful, that is not
   entirely read-only, or that causes side effects while invoking a safe
   method.  What is important, however, is that the client did not
   request that additional behavior and cannot be held accountable for
   it. [...]

Incidentally, guarantee C does solve the throttling problem -- if you get N
replays, you get promise of 1/(N+1) throttled resource available to you.
Deployments which do this with GETs may want to deploy the measures to make
N
very small.  Also, since they already keep track of the state for throttling
purposes, they might add a strike register on top of that.

>
> 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 ;-)
>

Why not 2?  What is the difference between 1 and 2?  2 and 3?  3 and 24?
None
of the proposed attacks distinguishes 1 replay and N replays in qualitative
ways (as opposed to giant semantic leap between 0 and 1 replay); only in how
much damage you can do, or how much information you can extract from the
side
channel.

  -- Victor.