[TLS] The case for a single stream of data

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

I wanted to start a separate thread on this, just to make some small
aspects of replay mitigating clear, because I'd like to make a case for TLS
providing a single-stream, which is what people seem to be doing anyway.

Let's look at the DKG attack. There are two forms of the attack, one is as
follows:

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

In this case, server-side signaling such as the X-header trick doesn't work
at all. But thankfully this attack is equivalent to an ordinary socket
interference attack. E.g. if an attacker today suppressed a server response
to a HTTP request, then the client will do its retry logic. It's the same,
and I think everything is compatible with today's behavior.

Next is the more interesting form of the attack:

"Client sends a request with a 0-RTT section. For some reason the server
can't reach the strike register or single use cache, and falls back to
1-RTT. Server accepts the request over 1-RTT.  Then a short time later, the
attacker replays the original 0-RTT section."

In this case, server side signaling to the application (such as the neat X-
header trick) also doesn't work, and is not backwards compatible or secure
by default. It doesn't work because the server application can't be made
idempotent from "outside" the application, so any signaling is
insufficient, and is equivalent to the Exactly-Once message delivery
problem in distributed systems. Since a request might be retried as in case
1, it needs an application-level idempotency key, or a delay-and-retry
strategy (but replay will break this). There's some detail on all this in
the review. End result is that a server-side application that was never
designed to reach duplicates may suddenly be getting exactly one duplicate
(that's all the attack allows, if servers reject duplicate 0-RTT).

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 might wait its retry period, do a poll,
and only then retry the request. If the TLS implementation signals the
original  0-RTT failure to the client, as if it were a connection error,
everything is backwards compatible again. Well mostly; to be properly
defensive, the client's retry time or polling interval needs to be greater
than the potential replay window, because only then can it reason about
whether the original request succeeded or not. If there is a strict maximum
replay window, then this behavior is enforceable in a TLS implementation:
by delaying the original failure notification to the client application by
that amount.

Of course browsers won't do this, and that's ok. Browsers have decided that
aggressive retries is best for their application space. But careful clients
/need/ this; and it's not just about backwards compatibility. It is a
fundamental first-principles requirement for something that uses an
eventually consistent data store. We can say don't use 0-RTT, but that's
not practical, for reasons also in the review.

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.

But it also has implications for middle-boxes: a TLS reverse proxy needs to
either not use 0-RTT on the "backend" side, or it needs to use it in very
careful way; accepting 0-RTT from the original client, only if the backend
also accepts a 0-RTT section from the proxy. This is to avoid the case
where the client can't reason about the potential for a replay between the
proxy and the backend. It's doable, but gnarly, and slows 0-RTT acceptance
down to the round trip between the client and the backend, via the proxy.

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.

O.k. so all of that the above might be a bit hairy: but I want to take away
from it at this stage is that splitting the early_data and application_data
at application level isn't particularly helpful; the server-side can't
really use this information anyway, because of the Exactly-Once problem.
Client side signaling does help though, and a simple safe-by-default
mechanism there is to behave as if the connection has failed, but after
writing the first section of data. E.g. in s2n this would be ...

conn = s2n_connect(); // Client makes a connection
r = s2n_write(conn, "GET / HTTP/1.1 ... "); // Client writes some data, we
stuff it in the 0-RTT and send it. This write succeeds. From the client's
perspective, it may or may not have been received; that's normal.

/* At this point the 0-RTT data is rejected by the server, and so it might
be replayable  ... iff the server side strike-register or
   cache had a problem.

   A pedantically correct TLS library might then pause here for 10 seconds,
or if it's non-blocking, then set a timer so that nothing can happen on
conn for the next 10 seconds. Browsers could turn this behavior off, since
they retry aggressively anyway. But it's a secure default that is backwards
compatible.
*/

r = s2n_read()/s2n_write()/s2n_shutdown();  // At this point, s2n returns
failure. It's as if the connection failed. The client can implement its
retry strategy, if any, safely; the request won't be replayed at this
point.

r = s2n_connect(); // Client makes a new connection for a retry.


A slightly higher level API is probably more realistic, because there's a
potential to optimize for connection re-use. There's really no need to tear
down the whole connection and start-over. It's safe to proceed to 1-RTT if
the delay has expired. A higher level API would fix that, but this is just
the "safe by default" API I'm outlining.  Again, all I want to take away is
that all of this is doable safely with a single stream.


-- 
Colm