On Fri, Jun 2, 2017 at 2:39 PM, Victor Vasiliev <vasi...@google.com> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
