Re: [quicwg/base-drafts] Receiver's behavior on key update (#2791)

[Kazuho Oku <[e-mail]>]

@DavidSchinazi Thank you for your comments. As I am uncertain what the correct approach is, I have so far tried to keep this PR a clarification of what's already written.

#2792 is the issue that discusses the problem in the current algorithm.

> The algorithm you describe actually uses 3 receive keys: you have the old one, the current one, and the new one. The new algorithm only overwrites the old keys with the new ones if decryption succeeds, which requires keeping 3 keys in memory while you're decrypting. The minimal algorithm immediately overwrites the old key when receiving the new packet, and that only requires keeping two keys in memory.

Current text states that a new key is computed every time when a received packet specifies an epoch for which a key has not been installed. This process is repeated until packet unprotection using that key succeeds and the key gets installed. Quoting from the current text: _"A receiving endpoint detects an update when the KEY_PHASE bit does not match what it is expecting. It creates a new secret (see Section 7.2 of [TLS13]) and the corresponding read key and IV using the KDF function provided by TLS."_

So at the moment, the text only requires an endpoint to retain 2 keys in state, and that is in line with "MAY limit to 2 keys." However, such algorithm does have side channel vulnerability, hence we need to discuss how to fix the issue (see #2792).



-- 
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/2791#issuecomment-502895107