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

The server shouldn't use a token for much #1647

Closed
martinthomson opened this issue Aug 10, 2018 · 1 comment · Fixed by #1704
Closed

The server shouldn't use a token for much #1647

martinthomson opened this issue Aug 10, 2018 · 1 comment · Fixed by #1704
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.

Comments

@martinthomson
Copy link
Member

The token that a server provides in Retry or NEW_TOKEN isn't authenticated. It can be used multiple times and it isn't folded into the handshake. This is an explicit limitation of the design. Neither client nor server can therefore rely on its contents for much. A server can ensure that the token is self-authenticating (by including a MAC or self encrypting it with an AEAD, for instance), but it shouldn't really use the information beyond its immediate purpose: address validation.
@martinthomson martinthomson added design An issue that affects the design of the protocol; resolution requires consensus. -transport labels Aug 10, 2018
@mikkelfj
Copy link
Contributor

If adding such advice, please be specific about encryption is not authentication. Although QUIC implementers would or should now, it could easily be missed by infrastructure operators. Merely stating AEAD or MAC can easily be misread as golang.encrypt(x) should be fine.

martinthomson added a commit that referenced this issue Aug 27, 2018
@martinthomson
Tokens are a mess
bbef7aa 
We can't realistically authenticate all tokens with up to three Retry
packets and the NEW_TOKEN message.  So they aren't really safe for much.
Describe the limitations and advise a very narrow usage.

I really hope that this choice doesn't bite us later.  It doesn't feel
that good, but I don't know how to fix this without going back to just
one Retry (and even then a solution would be ugly).

Closes #1647.
@martinthomson martinthomson mentioned this issue Aug 27, 2018
Merged
@mnot mnot added the has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. label Mar 5, 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
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Tokens are a mess quicwg/base-drafts
3 participants
@martinthomson @mnot @mikkelfj