New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rules for discarding old keys #1636
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -625,47 +625,51 @@ After QUIC moves to a new encryption level, packet protection keys for previous | |
encryption levels can be discarded. This occurs several times during the | ||
handshake, as well as when keys are updated (see {{key-update}}). | ||
|
||
QUIC endpoints MUST retain keys until they are no longer needed. If packets | ||
from a lower encryption level contain CRYPTO frames, frames that retransmit that | ||
data MUST be sent at the same encryption level. Similarly, an endpoint | ||
generates acknowledgements for packets at the same encryption level as the | ||
packet being acknowledged. Thus, it is possible that keys for a lower | ||
Packet protection keys are not discarded immediately when new keys are availble. | ||
If packets from a lower encryption level contain CRYPTO frames, frames that | ||
retransmit that data MUST be sent at the same encryption level. Similarly, an | ||
endpoint generates acknowledgements for packets at the same encryption level as | ||
the packet being acknowledged. Thus, it is possible that keys for a lower | ||
encryption level are needed for a short time after keys for a newer encryption | ||
level are available. | ||
|
||
An endpoint can only discard keys for a given encryption level only after it has | ||
both received and acknowledged all CRYPTO frames for that encryption level and | ||
when it has had all CRYPTO frames for that encryption level acknowledged by its | ||
An endpoint cannot discard keys for a given encryption level unless it has both | ||
received and acknowledged all CRYPTO frames for that encryption level and when | ||
it all CRYPTO frames for that encryption level have been acknowledged by its | ||
peer. However, this does not guarantee that no further packets will need to be | ||
received or sent at that encryption level because a peer might not have received | ||
all the acknowledgements necessary to reach the same state. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This paragraph seems duplicative of the preceding one. Can they be consolidated? Or if they are substantially different, the difference highlighted? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, I think so. The previous paragraph is intended to highlight the reasons why keys might be retained in a general sense. The second paragraph is intended to be more precise about what the requirements are. A small tweak to the lead-in of each should help emphasize the difference. |
||
|
||
After all CRYPTO frames for a given encryption level have been either sent or | ||
received and the corresponding acknowledgments have been received or sent, an | ||
endpoint starts a timer. To limit the effect of packet loss around a change in | ||
keys, endpoints MUST retain packet protection keys for that encryption level for | ||
at least three times the current Retramsmission Timeout (RTO) interval as | ||
defined in {{QUIC-RECOVERY}}. Retaining keys for this interval allows packets | ||
containing CRYPTO or ACK frames at that encryption level to be sent if packets | ||
are determined to be lost or new packets require acknowledgment. While this | ||
timer is running, an endpoint MUST use the most recent packet protection keys | ||
for all packets, except to protect packets containing CRYPTO and ACK frames for | ||
the older encryption level. These packets MAY also include PADDING frames. | ||
After all CRYPTO frames for a given encryption level have been sent and all | ||
expected CRYPTO frames received, and all the corresponding acknowledgments have | ||
been received or sent, an endpoint starts a timer. To limit the effect of | ||
packet loss around a change in keys, endpoints MUST retain packet protection | ||
keys for that encryption level for at least three times the current | ||
Retramsmission Timeout (RTO) interval as defined in {{QUIC-RECOVERY}}. | ||
Retaining keys for this interval allows packets containing CRYPTO or ACK frames | ||
at that encryption level to be sent if packets are determined to be lost or new | ||
packets require acknowledgment. | ||
|
||
Though an endpoint might retain older keys, new data MUST be sent at the highest | ||
currently-available encryption level. Only ACK frames and retransmissions of | ||
data in CRYPTO frames are sent at a previous encryption level. These packets | ||
MAY also include PADDING frames. | ||
|
||
Once this timer expires, an endpoint MUST NOT either accept or generate new | ||
packets using those packet protection keys. An endpoint can discard packet | ||
protection keys for that encryption level. | ||
|
||
An endpoint can update keys multiple times (see {{key-update}}) while this timer | ||
runs. In that case, packets protected with the newest packet protection keys | ||
and packets sent two updates prior will appear to use the same keys. After the | ||
handshake is complete, endpoints only need to maintain the two latest sets of | ||
packet protection keys and MAY discard older keys. | ||
|
||
Updating keys frequently can cause packets to be effectively lost. However, key | ||
updates can only be performed once per round trip time. This means that packets | ||
that are delayed or reordered will be identified as lost before replacement of | ||
packet protection keys is a problem. | ||
Key updates (see {{key-update}}) can be used to update 1-RTT keys before keys | ||
from other encryption levels are discarded. In that case, packets protected | ||
with the newest packet protection keys and packets sent two updates prior will | ||
appear to use the same keys. After the handshake is complete, endpoints only | ||
need to maintain the two latest sets of packet protection keys and MAY discard | ||
older keys. Updating keys multiple times rapidly can cause packets to be | ||
effectively lost if packets are significantly delayed. Because key updates can | ||
only be performed once per round trip time, only packets that are delayed by | ||
more than a round trip will be lost as a result of changing keys; such packets | ||
will be marked as lost before this, as they leave a gap in the sequence of | ||
packet numbers. | ||
|
||
|
||
# QUIC Packet Protection {#packet-protection} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"and when
itall"