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

[Ilari Liusvaara <[e-mail]>]

On Sun, Mar 22, 2015 at 05:59:46PM -0700, Andrey Jivsov wrote:
> On 03/22/2015 02:49 PM, Eric Rescorla wrote:
> >
> >A MORE REALISTIC ATTACK
> >During the interim meeting, DKG observed that you could produce the
> >same "I've forgotten my state" situation if you have a distributed
> >server. Say that the server operates in two loosely-synchronized
> >data centers. In that case, you can get the following situation
> >(shown without the attacker's intervention because of ASCII art
> >limitation
> >
> >  Client             Attacker            Server1              Server 2
> >
> >ClientHello [+0-RTT] -->
> >"POST /buy-something" ->
> >
> >                     ClientHello [+0-RTT] -->
> >                     "POST /buy-something" ->
> >                                         [Processes
> >                                          purchase]
> >
> >
> >
> >                     ClientHello [+0-RTT] ----------------------->
> >                     "POST /buy-something" ---------------------->
> >
> >
> >    <--------------------------------------  ServerHello [reject 0-RTT]
> >                                                  (+ rest of handshake)
> >
> >Finished --------------------------------------------------------->
> >"Post /buy-something" -------------------------------------------->
> >                                                   [Processes purchase]
> >
> >Again, the attacker will need to mess with the TCP channel, but their
> >ability to do so is part of our basic threat model [RFC 3552].
> >
> >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.
> 
> The SessionID-like fallback is a problem for a "broadcast" of the single
> "POST /buy-something" (via a replay of a captured message). Had the Server 2
> above rejected the ClientHello [+0-RTT] which was intended for Server 1
> (orbit1), there would be no problem.

I think there would still be a problem: The transaction would get retried
(there might be a dialog to shift the blame on user).

I don't see a way of eliminating this "forking" attack without essentially
eliminating 0-RTT (since client doesn't prove that its exchange key was
correct until handshake is complete, and at that point you can start sending
data anyway).
 
> One way to solve this is to say that the server must *fail* 0-RTT, as
> opposed to fallback to 1-RTT, if the "orbit" indicated in the ClientHello is
> not that of this server.

Won't help, and in general, you really don't want to fail TLS handshake
unless you know the handshake with that client can never succeed (e.g.
not supporting secure enough crypto).

> The only requirement here is that the server always knows its orbit. Servers
> must have different orbit IDs if they cannot handle simultaneous receipt of
> identical "POST /buy-something".

As noted above, you can use server that has different orbit as the second
server in attack.

Heck, in above diagram, the second server actually _rejects_ the 0RTT.
You propose additionally rejecting the connection, which will get retried.

Heck, I think the "forking" attack might actually work better in practice
with servers with different orbit IDs than with the same orbit ID, since
the latter could actually signal that replay is happening to the client.


-Ilari