Rules for discarding old keys #1636
Conversation
This is - at its core - simple. When you are done with keys, set a timer. Working through all the ramifications and defining this precisely takes more words than I'd originally anticipated. Closes #1544.
draft-ietf-quic-tls.md
Outdated
| 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 |
There was a problem hiding this comment.
Pick an only, but only one.
draft-ietf-quic-tls.md
Outdated
| when it has had all CRYPTO frames for that encryption level 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.
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.
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.
draft-ietf-quic-tls.md
Outdated
| all the acknowledgements necessary to reach the same state. | ||
|
|
||
| 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 |
There was a problem hiding this comment.
Given that each encryption level other than 0-RTT includes CRYPTO frames in both directions, I'd question the use of "either" here -- after all outgoing CRYPTO frames have been sent and all expected CRYPTO frames have been received, and the corresponding acknowledgements have also been sent and received.
draft-ietf-quic-tls.md
Outdated
| 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. |
There was a problem hiding this comment.
Talking about the "most recent packet protection keys" feels a little jarring here, since you're actually talking about encryption levels in this section. This doesn't flow as clearly if you mix in key updates at the same time.
Perhaps "New data MUST be sent at the highest currently-available encryption level, but ACK frames and retransmissions of CRYPTO frames from prior encryption levels continue to be sent at that encryption level."
draft-ietf-quic-tls.md
Outdated
| 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. |
There was a problem hiding this comment.
Make the transition to discussing key updates more explicit, if you need to do it in this section. Maybe, "Key updates in the 1-RTT encryption level do not require that keys from other encryption levels have already been discarded." I'd be inclined to move the rest of the key update discussion to that section and leave it with that statement.
Wherever that discussion lands, it feels like these two paragraphs need to merge. Something like "Frequent key updates could create confusion about which generation of 1-RTT keys were used to protect the packet. To mitigate this, key updates can be performed only once per RTT. This means...."
There was a problem hiding this comment.
The mitigation is a structural one - we don't say "don't update too often", instead it's more or less impossible to update that often (peers could update more often if they synchronized their efforts, but the floor is half an RTT). I'll reword with these comments in mind though.
draft-ietf-quic-tls.md
Outdated
| 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 |
This is - at its core - simple. When you are done with keys, set a
timer. Working through all the ramifications and defining this
precisely takes more words than I'd originally anticipated.
Closes #1544.