Re: [quicwg/base-drafts] Clarify the side-effect of frequent key updates (#2788)

[Marten Seemann <[e-mail]>]

I disagree that this is editorial an PR. 

As I understand, in the current text we're
1. Limiting the the frequency of key updates to avoid the deadlock in the case of frequent key updates (#2214). This is achieved by requiring a peer to not update keys to N+1 before receiving an acknowledgement for a packet sent at key phase N (which effectively limits key updates to no more than once per RTT).
1. For crypto hygienic reasons (and to limit memory consumption), we're only keeping old keys alive for a maximum of 3 PTOs, and dropping them afterwards.
1. If key updates are performed more frequently than once per 3 PTOs, endpoints MAY drop old keys sooner (again, in order to limit memory consumption). Note that this leads to (effective) packet loss if there's sufficient reordering of packets encrypted with the old keys. However, if there's no reordering, no packets are lost.

This PR changes the text such that a peer could effectively refuse to update to the new keys for a period of 3 PTO, thereby inducing massive packet loss on all packets encrypted with the new key phase, even in the absence of packet reordering.

In my opinion, this change is therefore not editorial, but a design change. 
Furthermore, I'm also not convinced that this is the right way to go. The current text has the nice property that there's a very clear definition when a key update is allowed: as soon as you receive an acknowledgment for the current key phase. According to this PR, this clear definition is replaced by saying that a subsequent key update shouldn't happen within 3 PTOs. The problem is that the PTO is a local value, and peers might disagree about the precise value at any given time. Therefore, there's no clear point in time when a key update could be performed safely (i.e. without risking that the peer refuses to update keys).

-- 
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/2788#issuecomment-501597224