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

Clarify the state a client stores with a token #3150

Merged
merged 1 commit into from
Jan 17, 2020
Merged

Clarify the state a client stores with a token #3150

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 8 additions & 1 deletion draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Member

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?


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
Expand Down Expand Up @@ -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
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
using the same version. When selecting a token to use, clients do not need to
using the same version. When selecting a token to use, a client does not need to

Copy link
Member

Choose a reason for hiding this comment

The 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
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
the choice of possible application protocols, session tickets, or other
the choice of application protocol or the value of any session ticket being used.

connection properties.
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
connection properties.


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
Expand Down