Original text:
The process of creating new packet protection keys for receiving packets could reveal that a key update has occurred.  An endpoint MAY <del> perform this process as part of packet processing, but this creates a timing signal that can be used by an attacker to learn when key updates happen and thus the value of the Key Phase bit in certain packets.  Endpoints MAY instead defer the creation of the next set of receive packet protection keys until some time after a key update completes, up to three times the PTO; see old-keys-recv. </del>  Once generated, the next set of packet protection keys SHOULD be retained, even if the packet that was received was subsequently Phase bit alone can be used to select keys. An endpoint MAY allow a period of approximately the Probe Timeout <del> (PTO; see QUIC-RECOVERY) after receiving a packet that uses the new key generation before it creates the next set of packet protection keys.  These updated keys MAY replace the previous keys at that time. With the caveat that PTO is a subjective measure - that is, a peer could have a different view of the RTT - this time is expected to be long enough that any reordered packets would be declared lost by a peer even if they were acknowledged and short enough to allow for subsequent key updates. </del>  Endpoints need to allow for the possibility that a peer might not be able to decrypt packets that initiate a key update during the period

Reviewer comments:
Some of this is just forward reference, but it does need a little more context. Also, there was a missing word.
This also no?
NAME said:
I'll roll this into the change for as it relates to the same basic text. I like the "promoting" idea, though I'm not going to go back and rewrite everything to use it. Here, the important thing is to have words for current, next, and "subsequent next" to avoid making this more confusing than necessary. I think that I got it.
NAME said:
I can see an obvious missing word in there at a minimum. I can see some opportunities for clarification here though, so I'll give it a go. Breaking the ordering dependencies between sections is tricky though. It might just be that we need a little redundancy.
This is a big help; thank you!

Revised text:
The process of creating new packet protection keys for receiving packets could reveal that a key update has occurred.  An endpoint MAY  <ins> generate new keys as part of packet processing, but this creates a timing signal that could be used by an attacker to learn when key updates happen and thus leak the value of the Key Phase bit. Endpoints are generally expected to have current and next receive packet protection keys available.  For a short period after a key update completes, up to the PTO, endpoints MAY defer generation of the next set of receive packet protection keys.  This allows endpoints to retain only two sets of receive keys; see old-keys-recv. </ins> Once generated, the next set of packet protection keys SHOULD be retained, even if the packet that was received was subsequently Phase bit alone can be used to select keys. An endpoint MAY allow a period of approximately the Probe Timeout  <ins> (PTO; see QUIC-RECOVERY) after promoting the next set of receive keys to be current before it creates the subsequent set of packet protection keys.  These updated keys MAY replace the previous keys at that time.  With the caveat that PTO is a subjective measure - that is, a peer could have a different view of the RTT - this time is expected to be long enough that any reordered packets would be declared lost by a peer even if they were acknowledged and short enough to allow a peer to initiate further key updates. </ins> Endpoints need to allow for the possibility that a peer might not be able to decrypt packets that initiate a key update during the period