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.

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

Merged
merged 4 commits into from Jun 18, 2019
Merged

Conversation

martinthomson
Copy link
Member

As agreed in London and Tokyo.

Closes #2180.

As agreed in London and Tokyo.

Closes #2180.
@martinthomson martinthomson added design An issue that affects the design of the protocol; resolution requires consensus. -transport labels May 22, 2019
Copy link
Contributor

@marten-seemann marten-seemann left a 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
Copy link
Contributor

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.

Copy link
Contributor

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.
@martinthomson
Copy link
Member Author

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Said below, BTW.

Copy link
Member

@kazuho kazuho left a 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.

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
Copy link
Member

@kazuho kazuho Jun 11, 2019

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.

Copy link
Contributor

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.

@martinthomson martinthomson added editorial An issue that does not affect the design of the protocol; does not require consensus. and removed design An issue that affects the design of the protocol; resolution requires consensus. labels Jun 18, 2019
@martinthomson martinthomson merged commit 9618d5b into master Jun 18, 2019
@martinthomson martinthomson deleted the same-ch-retry branch June 18, 2019 22:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Is Retry a new connection or what?
5 participants