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
Clients use the same crypto handshake after Retry #2746
Changes from 3 commits
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 | ||||
---|---|---|---|---|---|---|
|
@@ -3885,14 +3885,17 @@ the connection ID as part of its token validation logic (see | |||||
The next Initial packet from the client uses the connection ID and token values | ||||||
from the Retry packet (see {{negotiating-connection-ids}}). Aside from this, | ||||||
the Initial packet sent by the client is subject to the same restrictions as the | ||||||
first Initial packet. A client can either reuse the cryptographic handshake | ||||||
message or construct a new one at its discretion. | ||||||
first Initial packet. A client MUST use the same cryptographic handshake | ||||||
message it includes in this packet. A server MAY treat a packet that | ||||||
contains a different cryptographic handshake message as a connection error or | ||||||
discard it. | ||||||
|
||||||
A client MAY attempt 0-RTT after receiving a Retry packet by sending 0-RTT | ||||||
packets to the connection ID provided by the server. A client that sends | ||||||
additional 0-RTT packets without constructing a new cryptographic handshake | ||||||
message MUST NOT reset the packet number to 0 after a Retry packet; see | ||||||
{{packet-0rtt}}. | ||||||
packets to the connection ID provided by the server. A client MUST NOT change | ||||||
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.
Suggested change
|
||||||
the cryptographic handshake message it sends in response to receiving a Retry. | ||||||
|
||||||
A client MUST NOT reset the packet number to 0 for any packet number space after | ||||||
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. Do we need to say "to 0"? I think it'd be better to just omit "to 0", because resetting the packet number does not necessary mean that it goes to zero. It is totally reasonable for an endpoint to start it's packet number from one. 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. It says that you must not reset to zero. It does not matter if you do not necessarily reset to 0 if you sometimes can. I'm not sure why 0 is important in higher packer number spaces, but if it is, it must be stated. |
||||||
processing a Retry packet; {{packet-0rtt}} contains more information on this. | ||||||
|
||||||
A server acknowledges the use of a Retry packet for a connection using the | ||||||
original_connection_id transport parameter (see | ||||||
|
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 it MUST NOT reset the packet number to 0.
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.
Said below, BTW.