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

[Victor Vasiliev <[e-mail]>]

On Thu, Jun 1, 2017 at 7:59 PM, Colm MacCárthaigh <[e-mail]> wrote:

> On Thu, Jun 1, 2017 at 1:50 PM, Victor Vasiliev <[e-mail]>
> wrote:
>
>> 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.
>>
>
> It's not just a difference in the number of duplicates. With retries, the
> client maintains some control, so it can do things like impose delays and
> update request IDs. Bill followed up with an exactly relevant example from
> Token Binding where the retry intentionally has a different token value.
> That kind of control is lost with attacker driven replays.
>

I am not sure I understand the context in which this is relevant.  I
cannot imagine anyone delay the 1-RTT fallback, given that 0-RTT is
expected to fail regularly.  I also don't understand how changing
request ID would help -- I would assume that for retry safety, you'd
actually want the ID to be the same across all attempts.  Could you give
me a scenario where this actually changes the security properties of the
system?

(I understand the tokbind case -- but tokbind 0-RTT has different
operational requirements from plain TLS; those are documented in
draft-ietf-tokbind-tls13-0rtt and are somewhat out of scope for this
conversation)


> But even if we focus on just the number; there is something special about
> allowing 0 literal replays of a 0-RTT section; it is easy for users to
> confirm/audit/test. If there's a hard-guaranteee that 0-RTT "MUST" never be
> replayable, then I feel like we have a hope of producing a viable 0-RTT
> ecosystem. Plenty of providers may screw this up, or try to cut corners,
> but if we can ensure that they get failing grades in security testing
> tools, or maybe even browser warnings, then we can corral things into a
> zone of safety. Otherwise, with no such mechanism, I fear that bad
> operators will cause the entire 0-RTT feature to be tainted and entirely
> turned off over time by clients.
>

You can't really audit this property, since you never have a
comprehensive list of endpoints to which a 0-RTT can be replayed.


>
>> Sure, but this is just an argument for making N small.  Also, retrys can
>> also
>> be directed to arbitrary nodes.
>>
>
> This is absolutely true, but see my point about the client control.
> Regardless, it is a much more difficult attack to carry out. That is to
> intercept and rewrite a whole TCP connection Vs grabbing a 0-RTT section
> and sending it again.
>

It's within the scope of the threat model.


>
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'm just saying that it absolutely will happen, and I don't think any kind
> of lawyering about the HTTP spec and REST will change that. Folks use GETs
> for non-idempotent side-effect-bearing APIs a lot. And those folks don't
> generally understand TLS or have anything to do with it. I see no real
> chance of that changing and it's a bit of a deceit for us to think that
> it's realistic that there will be these super careful 0-RTT deployments
> where everyone from the Webserver administrator to the high-level
> application designer is coordinating and fully aware of all of the
> implications. It crosses layers that are traditionally quite far apart.
>
> So with that in mind, I argue that we have to make TLS transport as secure
> as possible by default, while still delivering 0-RTT because that's such a
> beneficial improvement.
>

Well, 0-RTT is inherently unsafe in a sense that it could be retried
at least one time.  This means that we have to draw a line somewhere.
Safe requests seem like a fine line to draw, in a sense that the
ecosystem is already free to try and retry GET requests at will (if you
don't retry yourself, your HTTP proxy might).  If you believe we should
use a more conservative approach, I am happy to hear your suggestions.


>
>
>> 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.
>>
>
> Yep; but I think /this/ risk is manageable and tolerable. Careful clients,
> like the token binding case, can actually mitigate this. I've outlined the
> scheme. For careless clients, like browsers, they can mostly ignore this;
> since they retry so easily anyway, it's no worse.
>

The problem is not just that it's a retry, but it also can be done
out-of-order.

Imagine I have a configuration system, and my client can take out a
global lock for some operation, and normally an update to it looks like
this:

  1. GET to check if the current state needs updating.
  2. POST to take a lock.
  3. GET to check if current state still holds.
  4. POST to update the data held by the lock.
  5. POST to release the lock and publish the notification.
  6. GET to ensure the lock was released.

Now, imagine the following attack:

  a) Between (1) and (2), the attacker resets the TCP connection, after
     the client got the response and the session ticket.
  b) Since the client has the ticket, it 0-RTTs the POST to take out a
     lock.
  c) Attacker redirects the client to another datacenter, which cannot
     accept 0-RTT, so it switches to 1-RTT.
  d) During (b) and (c), the attacker records a transcript of 0-RTT
     request to take out a lock.
  d) The rest of (2)-(6) proceed in normal fashion via client talking to
     the distant datacenter.
  e) Attacker replays the lock being taken out in the datacenter where
     0-RTT would succeed; the lock now is in place, and the client has
     no idea about it.

Because the application layer cannot reasonably assume that such
reordering can happen, it is not acceptable to 0-RTT the POST in #2.



> But there is *no* proposed mitigation for replayable 0-RTT. So I don't
> think that's manageable. Just trying to make a data-driven decision. If
> someone presents an alternative mitigation (besides forbidding replays),
> I'll change my mind.
>

The proposed mitigation is the application-layer profile prohibiting
unsafe requests via 0-RTT.


>
>
>> 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.
>>
>
> Throttling GET requests happens all of the time and is an important
> security and fairness measure used by many deployed systems. 0-RTT would
> break it. That's not ok.
>
> I don't think it is at odds with RFC 7231 ... which also defines the 503
> status code.
>

As I said, the N may vary and can be set by the service operator
depending on what kind of infrastructure they run.  It might be much
easier for a service to increase its throttling thresholds 10x and set
N=10, than to set N=1.

  -- Victor.