Clarify use of the generation field here, which is introducing a new concept
not directly touched on by the QUIC RFCs, which just deal in the Key Phase bit.
Provide examples for the first few generation numbers (for example, presumably
the first 1-RTT EL key has a generation of 0). Also clarify how this interacts
with the temporal behaviour of the key update process (since old keys are
retained to handle reordered packets). Presumably once a new key exists, it is
logged with a new generation number and the old key is eventually given a
key_discarded event with the old generation number. But this should be
clarified.
As reported by @hlandau on the mailing list:
security:key_updated:
Clarify use of the generation field here, which is introducing a new concept not directly touched on by the QUIC RFCs, which just deal in the Key Phase bit. Provide examples for the first few generation numbers (for example, presumably the first 1-RTT EL key has a generation of 0). Also clarify how this interacts with the temporal behaviour of the key update process (since old keys are retained to handle reordered packets). Presumably once a new key exists, it is logged with a new generation number and the old key is eventually given a key_discarded event with the old generation number. But this should be clarified.
security:key_discarded:
As above.