From df0d32007d13b1d6748ed5d855f12a3cbca38c87 Mon Sep 17 00:00:00 2001 From: Nick Harper Date: Thu, 24 Oct 2019 14:47:58 -0700 Subject: [PATCH] Clarify the state a client stores with a token It is permissible for a client to do 0-RTT resumption with a NST from one connection and a token from another. This clarifies that a client only needs to associate a token (from a NEW_TOKEN frame) with the server it was from and no additional state, and that a server can't require that a token be from the same connection as the NST in use. --- draft-ietf-quic-transport.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index b43582b0a2..8b4611fa02 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -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 +consider other properties of the connection that is being attempted, including +the choice of possible application protocols, session tickets, or other +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