Re: [quicwg/base-drafts] Stateless Reset needs "on-path" proof (#1230)

[Kazuho Oku <[e-mail]>]

While I agree that this can be considered a deployment issue, I think we should forbid servers deploying the same static secret used for generating the stateless reset token among the servers that do not share the connection state, because it not only goes against what "authenticated" reset is but also has privacy concerns.

My understanding is that many of the server-side deployments that care about this are those that use BGP to distribute their packets among multiple POPs. Those operators tend to serve multiple hostnames.

That means unless we mandate such server operators to provide stateless reset tokens only in a secure manner, attackers can force a connection to terminate (by using a stateless reset token obtained from a different POP) and then see the SNI carried in the handshake of a new connection.

Therefore, I think that we should either forbid server deployments from sharing the static key without sharing connection state, or, look for a technical approach to prevent the attack.

One such approach would be something like below:
* for every QUIC connection, let the server advertise a "state-store ID" that designates the ID of the state-store that the connection is bound to
* let a Stateless Reset packet carry encrypted data, which is encrypted by a key (other than stateless reset token) derived from the server CID and the static key used to generate the stateless reset token
  * that encryption key will be sent together with the stateless reset token in the NEW_CONNECTION_ID frame
* a Stateless Reset packet will carry the "state-store ID" of the server that sends the Stateless Reset encrypted
* a client can compare the "state-store ID" of the connection with the value found in the Stateless Reset, and determine that:
  * if the values match, the connection has been reset
  * if the values do not match, the path is being rejected

WDYT?

-- 
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/1230#issuecomment-379953976