target = "https://www.rfc-editor.org/rfc/rfc9001#section-6.1"

# 6.1.  Initiating a Key Update
#
# Endpoints maintain separate read and write secrets for packet
# protection.  An endpoint initiates a key update by updating its
# packet protection write secret and using that to protect new packets.
# The endpoint creates a new write secret from the existing write
# secret as performed in Section 7.2 of [TLS13].  This uses the KDF
# function provided by TLS with a label of "quic ku".  The
# corresponding key and IV are created from that secret as defined in
# Section 5.1.  The header protection key is not updated.
# 
# For example, to update write keys with TLS 1.3, HKDF-Expand-Label is
# used as:
# 
# secret_<n+1> = HKDF-Expand-Label(secret_<n>, "quic ku",
#                                  "", Hash.length)
# 
# The endpoint toggles the value of the Key Phase bit and uses the
# updated key and IV to protect all subsequent packets.
# 
# An endpoint MUST NOT initiate a key update prior to having confirmed
# the handshake (Section 4.1.2).  An endpoint MUST NOT initiate a
# subsequent key update unless it has received an acknowledgment for a
# packet that was sent protected with keys from the current key phase.
# This ensures that keys are available to both peers before another key
# update can be initiated.  This can be implemented by tracking the
# lowest packet number sent with each key phase and the highest
# acknowledged packet number in the 1-RTT space: once the latter is
# higher than or equal to the former, another key update can be
# initiated.
# 
#    |  Note: Keys of packets other than the 1-RTT packets are never
#    |  updated; their keys are derived solely from the TLS handshake
#    |  state.
# 
# The endpoint that initiates a key update also updates the keys that
# it uses for receiving packets.  These keys will be needed to process
# packets the peer sends after updating.
# 
# An endpoint MUST retain old keys until it has successfully
# unprotected a packet sent using the new keys.  An endpoint SHOULD
# retain old keys for some time after unprotecting a packet sent using
# the new keys.  Discarding old keys too early can cause delayed
# packets to be discarded.  Discarding packets will be interpreted as
# packet loss by the peer and could adversely affect performance.

[[spec]]
level = "MUST"
quote = '''
An endpoint MUST NOT initiate a key update prior to having confirmed
the handshake (Section 4.1.2).
'''

[[spec]]
level = "MUST"
quote = '''
An endpoint MUST NOT initiate a
subsequent key update unless it has received an acknowledgment for a
packet that was sent protected with keys from the current key phase.
'''

[[spec]]
level = "MUST"
quote = '''
An endpoint MUST retain old keys until it has successfully
unprotected a packet sent using the new keys.
'''

[[spec]]
level = "SHOULD"
quote = '''
An endpoint SHOULD
retain old keys for some time after unprotecting a packet sent using
the new keys.
'''