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

[Martin Thomson <[e-mail]>]

Yes, if the extent of the state storage distribution matches the extent of the key distribution, which is a natural design, then this is naturally OK.

@kazuho, I'm struggling with your state store ID design.  If the state and key storage is co-extant, then the packet that hits a different store will generate a response that the client won't recognize as a valid stateless reset.  So I'm failing to see how the extra steps you describe help with the problem.

Unless you are suggesting that this key needs to be global (unlike the token, which is scoped to a particular zone).  I don't think going global works though.  An attacker can obtain a key for a given connection ID in one cluster and use it - in combination with the stateless reset oracle Mike described - to attack another.

If we wanted to prove that the server can generate the Stateless Reset without compromising later uses of the Stateless Reset, then we could feed the incoming packet into the process.  For example, rather than include the token in the stateless reset directly, it includes a constant value that is generated by using `HMAC(token, some fixed content)` (or use HKDF[1]).  A client can use that to detect that this is a stateless reset.  In addition, the reset might also include a separate proof of receipt such as `HMAC(token, incoming packet or part thereof)`.  A client might choose to ignore a stateless reset that had an invalid secondary proof.

Of course, the risk here is that clients don't track enough from their outbound packets to reconstruct the input to the HMAC.  After all, it requires tracking packet ciphertext - no other part of a packet is unpredictable enough.  So they might have to treat receipt of a possible stateless reset as a trigger to enable whatever tracking they need, after which they send another packet and hopefully get a stateless reset.  Aside from adding a whole round trip to the process, it just more than doubled the cost of a stateless reset at the server.

[1] We originally have another hash for stateless resets, but removed that in favour of the current, simpler design.

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