Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Rewrite text on timing leaks for key generation #4577

Merged
merged 4 commits into from
Jan 11, 2021
Merged

Rewrite text on timing leaks for key generation #4577

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
9681fb0
Rewrite text on timing leaks for key generation
martinthomson Jan 6, 2021
3d699da
Use current, next, subsequent
martinthomson Jan 6, 2021
c03a536
Don't bother with that
martinthomson Jan 6, 2021
51f3305
one PTO, not three
martinthomson Jan 11, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions draft-ietf-quic-tls.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1636,13 +1636,13 @@ in the network. In this case, the Key Phase bit alone can be used to select
keys.

An endpoint MAY allow a period of approximately the Probe Timeout (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
{{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 for subsequent key updates.
allow a peer to initiate further key updates.

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 when it retains old
Expand Down