Re: [quicwg/base-drafts] Can a client send 0-RTT data when receiving Retry? (#1507)

[Kazuho Oku <[e-mail]>]

> I don't think that token handling is all that difficult here.

One of the issues here is that an on-path or a man-on-the-side attacker can mount a cut-and-paste attack that replaces token with a different value.

Let me explain one possible attack, that happens in following steps:
1. attacker connects to the server and obtains a token that says "server-config=A"
2. client connects to the server and obtains a NST and a token that says "server-config=B". At this 
3. client tries to reconnect to the server using the NST and the token obtained in step 2
4. an attacker enforces a retry by sending a token obtained in step 1

At this point, client believes that it can send 0-RTT packets based on the negotiated settings in step 2, which is "server-config=B". The server would assume that the 0-RTT packets that it will receive is based on "server-config=C".

I am not sure how scary it sounds right now, however it could become a practical concern when we start adding extension frames to QUIC.

To avoid this type of attack, the server needs to do something like:
* store the server settings in the session ticket rather than the token. TLS stacks will need to provide an interface for that (if they do not provide one yet), or
* have a different STEK for every server-config, so that resumption will fail if the client provides tries to resume with a PSK that is not bound to the server-config found in the token

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1507#issuecomment-406347056