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

NEW_TOKEN and Retry tokens must be distinguishable #3127

Closed
martinthomson opened this issue Oct 22, 2019 · 3 comments · Fixed by #3128
Closed

NEW_TOKEN and Retry tokens must be distinguishable #3127

martinthomson opened this issue Oct 22, 2019 · 3 comments · Fixed by #3128
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects
Late Stage Processing

Comments

@martinthomson
Copy link
Member

We currently say that these tokens SHOULD be distinguishable by a server on the basis that an error in a NEW_TOKEN token is recoverable, but an error in a Retry token is fatal. I don't see why this can't be MUST. If we make it "MUST", then we can rely on this property in the design.
@martinthomson martinthomson added design An issue that affects the design of the protocol; resolution requires consensus. -transport labels Oct 22, 2019
@ianswett
Copy link
Contributor

Agreed, that'd be a useful property to rely on.

martinthomson added a commit that referenced this issue Oct 22, 2019
@martinthomson
Mandatory distinction between token types
7bed0b4 
Closes #3127.
@martinthomson martinthomson mentioned this issue Oct 22, 2019
Merged
@martinthomson martinthomson added the proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. label Oct 22, 2019
@marten-seemann
Copy link
Contributor

Does that property need to hold if there are bit flips in the token?
If you’re encrypting the token, this would be easy to ensure: put the distinguishing bit under crypto cover. If you’re using a map lookup, you’ll probably have to work a little bit harder.

@marten-seemann
Copy link
Contributor

Please ignore my last post, I mixed up Retry packets and Initials. Tokens in the client’s Initial are part of the AAD, so we don’t have to worry about bit flips.

@ianswett ianswett mentioned this issue Oct 22, 2019
Merged
@mnot mnot added this to Triage in Late Stage Processing Oct 27, 2019
@mnot mnot moved this from Triage to Consensus Emerging in Late Stage Processing Oct 31, 2019
@mnot mnot moved this from Consensus Emerging to Consensus Call issued in Late Stage Processing Nov 14, 2019
@mnot mnot moved this from Consensus Call issued to Consensus Declared in Late Stage Processing Nov 29, 2019
@mnot mnot added has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. and removed proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. labels Nov 29, 2019
Late Stage Processing automation moved this from Consensus Declared to Text Incorporated Nov 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects
Late Stage Processing
  
Issue Handled
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Mandatory distinction between token types quicwg/base-drafts
4 participants
@martinthomson @mnot @marten-seemann @ianswett