Re: [quicwg/base-drafts] Timing side-channel on key updates (#2792)

[MikkelFJ <[e-mail]>]

> I agree, there's not really a need to do key updates that frequently. However, I like the fact that we're currently defining a clear rule: An endpoint is allowed to update to N+1 as soon as it has received an acknowledgement for a packet sent at key phase N.

Perhaps we should state that an endpoint should precompute the key early but not update keys too frequently to prevent timing attacks and overhead.

> An endpoint that wants to ensure that no packets are dropped due to the unavailability of keys would have no choice but to wait >> 3 PTO. 

That is not necessarily a bad thing, but it is unfortunate that there is no clear definition. We could also say the idle timeout period.

As long as we compute keys using SHA256 it might not be a concern, but computing keys too frequently could exhaust safety parameters on other potentially faster algorithms.

-- 
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/2792#issuecomment-502053786