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

[Kazuho Oku <[e-mail]>]

@DavidSchinazi Thank you for the suggestions.

> the MUST stems from avoiding an attacker messing with the KEY_PHASE bit, not from out of order packets.

Yes. An endpoint should not calculate the next receive key whenever it receives a packet with a header claiming that it uses the next key phase, meaning that it needs to cache the next receive key. That leads us to "MUST at least two during a key update."

> An endpoint SHOULD retain a third receive key (the "past" key) so that it can unprotect older packets that arrive out-of-order.

While I like your suggested text for clarifying better how the keys are generated / dropped, this sounds like a new requirement. I think it's unnecessary (and also would oppose to introducing such a requirement).

Therefore, while incorporating the suggested text, I've instead went on to clarify how a 2-key design should replace the "past" key with the "future" key. Also, Instead of naming the three keys, I've changed the text to refer to the key phases using terms "current", "next", "previous", and to talk about their corresponding keys.

PTAL.

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