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

[Bill Cox <[e-mail]>]

On Fri, Jun 2, 2017 at 2:39 PM, Victor Vasiliev <[e-mail]> wrote:

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

A simpler attack over TLS 1.2 that has the same result:

a) An active attacker waits until she sees what she believes is a lock POST
request.  This can happen at any time during the connection, and the flight
is identified by metadata since it is encrypted.
b) The attacker holds the lock request, and keeps the connection to the
server alive by transmitting a byte to it every minute or so, and
terminates the client connection.
c) The client reconnects, and proceeds with steps 2-6
d) Attacker sends the request to obtain the lock, and now the resource is
locked.

For browsers, this attack seems simpler (no redirect to another data
center), and more powerful (can attack at any point in the stream).  It
obtains the same result (locked resource), and I do not see any simple
mitigation, other than to force clients to make all state changes
transactional.  I realize this attack requires browser retransmition, not
just TLS re-transmission, so it is fundamentally different.  However, isn't
the result the same or worse?

My feeling is that when talking to stateless 0-RTT servers, browsers should
send only idempotent HTTP requests, and accept less-than-perfect FS.  I
also feel they should avoid attempts at client auth over 0-RTT.  However,
when talking to servers that prevent replay (but not re-transmission) I
think browsers should be free to send any HTTP requests over 0-RTT, and
also attempt client auth.  The security properties of 0-RTT data are still
different, but for browsers, where it does not matter whether the
re-transmission is in the browser or TLS layer, the security seems
equivalent to me.

Bill