-
Notifications
You must be signed in to change notification settings - Fork 204
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
clarify how to handle Retry, as well as stating that a fixed mapping …
…bet. versions and salts is better than nothing
- Loading branch information
Showing
1 changed file
with
17 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2789,6 +2789,23 @@ following steps: | |
decrypts the embedded token and recovers the alternative initial salt, uses | ||
that to decrypt the payload of the Initial packet. | ||
|
||
* When sending a Retry in response to an Initial packet carrying an alternative | ||
version number, the server embeds the NEW_TOKEN token found in the Initial | ||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
kazuho
Author
Member
|
||
packet within the retry token it issues. Once the server receives a response | ||
from the client carrying that retry token and the path is validated, it | ||
decrypts the NEW_TOKEN token embedded in the retry token to recover the | ||
alternative initial salt that is to be used for unprotecting the packet | ||
payload. | ||
|
||
Instead of associating a new alternative initial salt to every NEW_TOKEN token, | ||
a server might map a fixed salt to each of the alternative version numbers it | ||
issues. Such design is not recommended, as an active attacker might build a | ||
list of known alternative version numbers and their initial salts and use that | ||
list to decrypt the payload of Initial packets using those alternative version | ||
numbers. But still, having a set of version numbers and initial salts used | ||
concurrently is considered better than just using the default values of QUIC in | ||
terms of preventing ossification. | ||
|
||
A server MUST NOT send a Version Negotitation packet in response to a long | ||
header packet with an alternative version number it has advertised. | ||
|
||
|
This is one possible design, for a server that wants to do minimal work. A server could, however, extract the salt and put it in the Retry token, no? We should word this as a suggested implementation, not as the only one.