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.

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

Strengthen 2119 language around tokens. #2123

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
6 changes: 3 additions & 3 deletions draft-ietf-quic-transport.md
Expand Up @@ -1610,15 +1610,15 @@ A resumption token SHOULD be constructed to be easily distinguishable from
tokens that are sent in Retry packets as they are carried in the same field.

If the client has a token received in a NEW_TOKEN frame on a previous connection
to what it believes to be the same server, it can include that value in the
to what it believes to be the same server, it SHOULD include that value in the
Token field of its Initial packet.

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
break continuity of identity with a server MAY discard tokens provided using the
NEW_TOKEN frame. Tokens obtained in Retry packets MUST NOT be discarded.

A client SHOULD NOT reuse a token in different connections. Reusing a token
A client MUST NOT reuse a token in different connections. Reusing a token
allows connections to be linked by entities on the network path
(see {{migration-linkability}}). A client MUST NOT reuse a token if it
believes that its point of network attachment has changed since the token was
Expand All @@ -1627,7 +1627,7 @@ interface. A client needs to start the connection process over if it migrates
prior to completing the handshake.

When a server receives an Initial packet with an address validation token, it
SHOULD attempt to validate it, unless it has already completed address
MUST attempt to validate it, unless it has already completed address
validation. If the token is invalid then the server SHOULD proceed as if
the client did not have a validated address, including potentially sending
a Retry. If the validation succeeds, the server SHOULD then allow the
Expand Down