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

[Marten Seemann <[e-mail]>]

> I also do not see why an endpoint need to update the key as frequently as couple of PTOs. Key update exists so that endpoints can replace the keys becoming weak after being used extensively. A key that becomes weak just after couple of PTOs should never be used. 

I agree with that, however, I'm very much in favor of having a clear-cut definition, instead of second-guessing what the peer's view of the PTO might be).

> I think what you are missing is "endpoint SHOULD retain old keys for a period of no more than three times the PTO" (quoting from section 6). As you can see, the current text already effectively refuses updates more frequent than every 3 PTO. Hence my argument that this is an editorial change.

This sets a **maximum** time on how long keys should be kept. I don't see how this would impose a limit on the frequency at all.

To the contrary, we say that as soon as you receive a packet with the new key phase, you immediately update your keys:
> A receiving endpoint detects an update when the KEY_PHASE bit does not match what it is expecting. It creates a new secret [...] and the corresponding read key and IV using the KDF function provided by TLS.

The spec goes on to clarify that IF you want to limit the number of keys, you drop **the old keys**:
> Endpoints MAY limit the number of keys they retain to two sets for removing packet protection and one set for protecting packets. Older keys can be discarded.

This leads to the risk that packets are dropped **in the case of significant reordering**. Every time this section talks about packet loss, it's always in the case of reordering.

> I think that this interpretation is incorrect; we already have the following in the spec: "an endpoint SHOULD NOT initiate a key update for some time after it has last updated keys; the RECOMMENDED time period is three times the PTO".

I think we have this text because we want to guarantee optimal performance on connections that experience significant amounts of reordering, and waiting for 3 PTOs is a good way to ensure that all old packets are actually received.

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