Re: [quicwg/base-drafts] Perform stateless reset token comparisons in constant time (#2993)

[Martin Thomson <[e-mail]>]

One thing that I'm trying to protect is the integrity of the specification and the analysis that (I hope) will come.  If we allow weaseling out of this sort of requirement, then the analysis has to allow for that too.

If you are using a hash map, then you can do as @kazuho suggests: use a PRP (a PRF would also work) to produce an intermediate value from the incoming value and compare that in non-constant time.  As long as the operation cannot be reversed by an attacker and the secret input to the PRP (i.e., the token) are handled in constant time, the secret doesn't leak.

We can't assume that resetting a connection is without cost.  QUIC has the nice property that connections can survive network flutters, which means that a lot of investment could be made in a connection.  (That's probably still inadvisable.)  A well-positioned attacker doesn't have to perform a huge amount of work to recover a stateless reset token, relative to the value they might gain in disrupting a "high-value" connection of that sort.

If we use a "MUST", then we're not stopping someone from deciding that this requirement doesn't apply to them.  But they would take responsibility for that, hopefully with some awareness of what is being risked.  Yes, we could use "MUST avoid leaking through timing side channels unless <X>", but determining what X needs to be is tricky as it depends so much on application protocol and other contextual stuff.

-- 
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/pull/2993#issuecomment-527694231