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
Conversation
As agreed in London and Tokyo. Closes #2180.
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.
Maybe it's more readable to combine the two paragraphs into one, or at least the part about generating the response to the Retry.
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 |
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.
This isn't just for 0-RTT.
We already have an editorial issue in this section; it needs breaking into subsections rather than combining long paragraphs into even longer ones. Thanks for catching the packet number thing. |
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 comment
The reason will be displayed to describe this comment to others. Learn more.
packets to the connection ID provided by the server. A client MUST NOT change | |
packets with the connection ID provided by the server. A client MUST NOT change |
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 |
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.
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.
LGTM modulo the point below.
draft-ietf-quic-transport.md
Outdated
packets to the connection ID provided by the server. A client MUST NOT 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 comment
The 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 comment
The 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.
As agreed in London and Tokyo.
Closes #2180.