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

[Kazuho Oku <[e-mail]>]

@mikkelfj Thank you for the suggestions.

> An endpoint SHOULD compute the secret and related receive and send keys of the next key phase ahead of time

> SHOULD transitionally maintain an older key to deal with late arriving packets for a duration of 3 PTO after switching to a new key phase.

It is my understanding that if we should make these non-editorial changes is an open issue (see #2792).

> (EDITORIAL NOTE: I'm struggling with when a key is fully retired and in violation because it is always possible that an earlier packet is received after a key switch which also carries the new key phase. You could formulate something but it gets complicated).

An endpoint should not call it a violation when it receives a packet carrying an awfully outdated key phase, because such behavior would allow an on-path attacker to disrupt a connection, by buffering a and injecting a very old packet. That also means that there's no reason to define when an old key is dropped.

> Maybe we can just use "successfully unprotect" instead of decrypt and authenticate. Or perhaps it is enough to authenticate without decrypting. Noting that these are parallel and separate steps in GCM that can be processed separately.

It is true that we use "decrypt and authenticate" as a synonym of "unprotect." I can see that it might be confusing. OTOH, we should never allow decryption or authentication as a separate operation, because that would lead to timing attacks.


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