Re: [TLS] The case for a single stream of data

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

On Wed, May 10, 2017 at 10:00 PM, Benjamin Kaduk <[e-mail]> wrote:
>
> However, I'm still not convinced that requiring strong 0-RTT non-replay is
> feasible/the right thing to do.
>

[ I've cut a lot for brevity, but hopefully what I've replied with can
address this, and the rest ]

The case for requiring servers, and especially middle-boxes to provide
strong 0-RTT non-replay is really the resource exhaustion, throttle
exhaustion and cache timing attacks. I think that's where the really
dangerous bugs are, the ones that will be exploited - maybe even
inadvertently - and that are a show-stopper for the stateless mitigation.
It just doesn't work.

Thankfully it's within our capabilities to fix this and there's nothing
logically impossible about providing non-replay for the 0-RTT sections.


> On 05/05/2017 11:28 AM, Colm MacCárthaigh wrote:
>
> "Client sends a request with a 0-RTT section. The attacker lets the server
> receive it, but suppresses the server responses, so the client downgrades
> and retries as a 1-RTT request over a new connection. Repeating the
> request".
>
> Does the client always downgrade?  We don't require it to do so, in TLS
> 1.3, though of course browsers would.
>

The current draft says that clients should only use tickets once, if they
do that, then the repeat attempt (even if it's still 0-RTT, with a
different ticket) is un-correlatable.

I feel like many applications that use delay-and-retry will see this and
> conclude that they should just not attempt to use 0-RTT.
>

Per the section of the original review about violation of layers and
separation of actors; this breaks the well-established relationship between
the layers. It's predictable that a site-administrator will enable 0-RTT
without any appreciation for the application-level impact. Vendors are
already providing 0-RTT in backwards compatible ways.

What is actually needed here, I think, is client-side signaling. Careful
> clients need to be made aware of the original 0-RTT failure.
>
> So for example, an SDK that writes to an eventually consistent data store
> may treat any 0-RTT failure as a hard failure, and *not* proceed to sending
> the request over 1-RTT. Instead it
>
>
> Right; nothing *requires* the client to retry failed 0-RTT as 1-RTT; the
> application can decide it's willing to take the risk or use some other
> strategy.  But I'm not convinced that the TLS stack needs to decide on its
> own, without application input.
>

I'm just describing the only backwards compatible safe-by-default scheme I
can concoct, it's definitely kludgey and awkward. For this thread, my main
take-away from it is that separating streams doesn't actually help the
application; instead, it's a timing thing.


> Does a careful client really need the TLS stack to signal connection
> error?  Surely the TLS stack will provide a mechanism to inquire as to the
> connection state, and whether 0-RTT was rejected.  The application could
> implement its own delay.
>

Yep, absolutely; but it'd be client-side signaling, and it's not
backwards-compatible or safe-by-default to rely on.


> And I read what you wrote in the github issue about how saying "don't use
> 0-RTT" is not practical, but I don't believe that it is universally true.
> Some (careful) applications will rightly consider the tradeoffs and decide
> to not use it.  On the web ... there are different forces at play, and it
> may well take a (security bug) name and website to cause webapp creators
> and framework authors to take proper notice.  But I am having a hard time
> squaring your point about careful clients with the point about
> non-practicality.  If there are careful clients, they will heed warnings;
> if just using warnings is not practical, then what are the careful clients
> doing?
>

I actually share the optimism here. I think it's workable for careful
clients, and I wouldn't hold 0-RTT hostage to the DKG corner case. I think
we should ship it. All I'm trying to get at is that separate streams are
needless complexity, and they seem to be getting ignored by implementors
anyway.

Right now there's a very weird take in the draft: let the server figure it
out by marking the data as replay-able. Well actually that doesn't work; on
the server side, the sections can't always be correlated, and even if they
were an application would still need its own anti-retry strategy. It's
well-meaning; but doesn't work. We should take it out.

Here's an example. Client has two tickets: AA and BB.

T1. Client makes 0-RTT request for /foo/ with ticket AA. Servers receives
the request and marks as replayable-data, maybe uses AA to derive a
convenient idempotency/anti-replay key (like the X- header trick).

T2. Client was blocked, Tries again, doesn't re-use the ticket, per the
draft. So repeats with 0-RTT again, with ticket BB. Same as before, except
now the key is derived from BB.

T3. Client tries again, this time over 1RTT. Per the draft, there's *no*
signaling of repayable data.

What on earth is a server side application suppose to do with this sequence
of events? None of these 3 requests can be correlated, unless the
application author added their own key ... in which case they don't need
any of this TLS-layer stuff.

Some applications mitigate this kind of problem client side, what I'm
pointing out there is that to work robustly, then a client needs to 1) know
about the 0-RTT failure, 2) know for how long the 0-RTT request may be
replayed.  With that small modification; a client can actually repair
failures too.

So if we want to fully mitigate DKG attacks, I think it is useful to hard
> cap the replay, say that it MUST be at most 10 seconds. And then worst
> case, a client that needs to be careful can wait 10 seconds. Note that the
> TLS implementation can do this on the client's behalf, by inserting a
> delay. Of course that means that for these kinds of applications, this
> means that 0-RTT delivers speed most of the time, but may occasionally slow
> things down by 10 seconds. I think that's an ok trade-off to make for
> backwards compatibility.
>
>
> Again, does this need to be in the TLS implementation or can the (careful)
> application do it?
>

I don't think a careful application can do it without a hard-cap; otherwise
a zombie write could come along at any time and invalidate its state.

That's one reason why the review suggests something else too:  just lock
> careful applications out, but in a mechanistic way rather than a "good
> intentions" way, by having TLS implementations *intentionally* duplicate
> 0-RTT sections.
>
>
> Err, regularly locking out careful applications is supposed to be a good
> thing?
>

Well, it locks out the careless ones, so yes ime, same as GREASE really :)


> (Again, the mandatory 10-second delay on 0-RTT rejection introduces huge
> processing time variance, which is a no-go in some environments.)
>

It needn't be mandatory; just the default. A careful client could do as
you're suggesting; handle this at a different layer.

-- 
Colm