Re: [quicwg/base-drafts] Why does stateless reset have to be checked after MAC failure (#2152)

[MikkelFJ <[e-mail]>]

Depending on implementation it can be very hard to do constant time.

Even if you compare keys in constant time, the cache latency can be much higher. For stateless resets I'd assume a lookup only happens once and then it is removed from, say, a hash table. That is, there is no cache latency difference between a valid and an invalid lookup. Compare this to connectionsID's that are looked up frequently. Here it is possible to guess to valid CID's based on lookup times.

But even if you do not have cache latency issues, you have hash collision issues. This makes a hash table unsuitable. The alternernative is binary tree, or a trie. The binary tree will be have to modified to do log N comparisons for all lookups even if the key is found higher up. And regardless a binary tree is much much slower than a hash table. Tries are very complex to implement correctly and must still be implemented for maximum search path comparison.

Another approach is to timestamp the lookup and busyloop until you reach, say, 100ns of cpu cycles after performaning the lookup in a hash table. This is still faster than a binary tree, but slower than the trie.

I seriously doubt most implementations would go out of their way to make resets effectively constants time.

So the question is - does that make most implementations trivial targets for DoS resets?
And what about guessing CID's?

How can practically protect against this, because trusting the implementation to be constant time is not realistic.

-- 
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/2152#issuecomment-524821286