Re: [TLS] 0-RTT and Anti-Replay

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

On Sun, Mar 22, 2015 at 2:49 PM, Eric Rescorla <[e-mail]> wrote:
>
>
> A SOMEWHAT CONTRIVED ATTACK
> This is all fine so far, but the abstraction you probably want TLS to
> supply to the application is that the data it sends in the first
> flight isn't lost even in this case. In order to accomodate this, the
> natural design is for the TLS stack to retransmit the plaintext in the
> client's first flight as the first data it sends under the new keys.
>
> An attacker can make use of this as follows. When the client sends
> the initial first flight he captures the TCP connection and makes his
> own TCP connection to the server, forwarding the first flight.
>
> Client                        Attacker                          Server
>
> ClientHello [+0-RTT] ------------>
> "POST /buy-something" ----------->
>
>                               ClientHello [+0-RTT] --------------->
>                               "POST /buy-something" -------------->
>
>                                                    [Processes purchase]
>                                  <---------- ServerHello [accept 0-RTT]
>                                                   (+ rest of handshake)
>
>
> The attacker just discards the server's response and then the server
> somehow forces the server to reboot (this is the hard part).

It's probably easier than rebooting in a real-world attack: the server
is vulnerable to state exhaustion attacks. For a primitive server, an
attacker can generate enough client randoms to exhaust the state
capabilities of the remote end. A more complicated server set-up might
use a distributed store, sharded on the client random data; but even
if they pay enough attention to use a salted hash of the client random
data for the shard key, it only changes the attack effort by a linear
factor.

> It's important to understand that this is a generic issue, not an
> issue with TLS in particular, so it's not like there's some other
> 0-RTT model we can lift and put into TLS that would solve the problem.

This probably opens a can of worms; but I think schemes that involve
an assumption of roughly synchronized time between clients and servers
can go quite a way to mitigating replay attacks too.

Also, I know it's groan-worthy: but a safe variant of 0RTT is to first
transit data opaquely, protected by a key that is only sent once the
server is authenticated. This makes optimistic execution impossible on
the server side, but it does preserve some of the benefits of network
throughput and latency.

> I would expect them to have relatively similar impacts on the wire,
> namely applications would self-designate certain data as replay-safe
> (e.g., HTTP GETs) and would send it in the first flight and then
> either let the stack retransmit (option 2) or retransmit themselves
> (option 3). This isn't that odd, since, as AGL observes, browsers
> already routinely retry some HTTP requests that appear to fail even for
> ordinary TLS (i.e., no HTTP response was received) so in those cases
> they have already circumvented the anti-replay guarantees supplied by
> TLS, but of course that's different from having TLS give up those
> guarantees.

I don't think it's a good idea to use browsers as the comparison here.
TLS is used extensively outside of browsers and many of those
applications do not retry like this, and rely on TLS as their
anti-replay mechanism.

-- 
Colm