-
Notifications
You must be signed in to change notification settings - Fork 204
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
Clarify the state a client stores with a token #3150
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -1741,7 +1741,8 @@ its Initial packet. Including a token might allow the server to validate the | |||||
client address without an additional round trip. A client MUST NOT include a | ||||||
token that is not applicable to the server that it is connecting to, unless the | ||||||
client has the knowledge that the server that issued the token and the server | ||||||
the client is connecting to are jointly managing the tokens. | ||||||
the client is connecting to are jointly managing the tokens. A client MAY use a | ||||||
token from any previous connection to that server. | ||||||
|
||||||
A token allows a server to correlate activity between the connection where the | ||||||
token was issued and any connection where it is used. Clients that want to | ||||||
|
@@ -1792,6 +1793,12 @@ able to reuse a token. To avoid attacks that exploit this property, a server | |||||
can limit its use of tokens to only the information needed to validate client | ||||||
addresses. | ||||||
|
||||||
Clients MAY use tokens obtained on one connection for any connection attempt | ||||||
using the same version. When selecting a token to use, clients do not need to | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It might be better to say: using the same "QUIC" version. Also, I think it might be a good idea to gather the discussion about applicability to one place. At the moment this PR scatters that to three places: one being the change above (and the first sentence of that paragraph, which already exists), and the provisions being added here. |
||||||
consider other properties of the connection that is being attempted, including | ||||||
the choice of possible application protocols, session tickets, or other | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
connection properties. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
|
||||||
Attackers could replay tokens to use servers as amplifiers in DDoS attacks. To | ||||||
protect against such attacks, servers SHOULD ensure that tokens sent in Retry | ||||||
packets are only accepted for a short time. Tokens that are provided in | ||||||
|
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 this sentence can be subsumed by the first sentence of the same paragraph that discusses the applicability of the token?