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

What if a client sends a NEW TOKEN frame? #2382

Closed
huitema opened this issue Jan 29, 2019 · 6 comments · Fixed by #2988
Closed

What if a client sends a NEW TOKEN frame? #2382

huitema opened this issue Jan 29, 2019 · 6 comments · Fixed by #2988
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
Late Stage Processing

Comments

@huitema
Copy link
Contributor

huitema commented Jan 29, 2019

Should the server just ignore it, or is is a protocol violation?
@ianswett
Copy link
Contributor

I vote for protocol violation.

@huitema
Copy link
Contributor Author

huitema commented Jan 29, 2019

The spec says nothing...

@martinthomson martinthomson added editorial An issue that does not affect the design of the protocol; does not require consensus. -transport labels Jan 29, 2019
@martinthomson
Copy link
Member

Yeah, there's no need to vote, this is just an omission. A protocol violation (or similar) is what we should mandate.

@huitema
Copy link
Contributor Author

huitema commented Jan 29, 2019

Playing devils' advocate: what about p2p apps? The token says, you can call me back from that address, I will accept it. The client is not saying anything untrue.

@mnot mnot added this to Design Issues in Late Stage Processing Feb 27, 2019
@mnot mnot moved this from Design Issues to Editorial Issues in Late Stage Processing Feb 27, 2019
martinthomson added a commit that referenced this issue Aug 26, 2019
@martinthomson
Only servers send NEW_TOKEN
9b95d3f 
This doesn't add rationale.  It doesn't have to.  See the issue
discussion for that rationale.

Closes #2382.
@martinthomson
Copy link
Member

I'll bite. Yes, a P2P app that used mutual authentication in a way that would allow a former server to associate a token with an attempt to connect to a peer that was previously a client, might be able to use NEW_TOKEN.

That's a little outside our remit. I'm going to take this as an editorial change on the understanding that a design issue could be opened to allow the asymmetry.

Anyone who is serious about that should also consider the fact that NewSessionTicket in TLS is potentially symmetrical by the same logic. Which suggests that 0-RTT isn't out of the question either.

@martinthomson martinthomson mentioned this issue Aug 26, 2019
Merged
@mikkelfj
Copy link
Contributor

On p2p there is the potential problem of relating a token to previously stored settings and observables from a previous session. This isn't well defined if the client specifies a new token. So perhaps it is better for each peer to "waste" a single 1-RTT connection the first time in a given direction.

Late Stage Processing automation moved this from Editorial Issues to Text Incorporated Aug 27, 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 editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
Late Stage Processing
  
Issue Handled
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Only servers send NEW_TOKEN quicwg/base-drafts
4 participants
@martinthomson @mikkelfj @huitema @ianswett