Re: [quicwg/base-drafts] Repeat tokens in all Initial packets (#2089)

[Christian Huitema <[e-mail]>]

huitema commented on this pull request.

I assume that we will process PR #2064 after this one. I am fine with the text, but I would like something said about server behavior. Client recommendations are mostly enforced when breaking them causes servers to reject packets...

>  Upon receiving the client's Initial packet, the server can request address
 validation by sending a Retry packet ({{packet-retry}}) containing a token. This
-token is repeated by the client in an Initial packet after it receives the Retry
-packet.  In response to receiving a token in an Initial packet, a server can
-either abort the connection or permit it to proceed.
+token is repeated by the client in all Initial packets after it receives the
+Retry packet.  In response to receiving a token in an Initial packet, a server
+can either abort the connection or permit it to proceed.
+
+As long as it is not possible for an attacker to generate a valid token for
+its own address (see {{token-integrity}}) and the client is able to return
+that token, it proves to the server that it received the token.
 

Define "proves". The token mechanism may be vulnerable to replay attacks.

> @@ -1590,9 +1588,11 @@ amount of data to a client in response to 0-RTT data.
 
 The server uses the NEW_TOKEN frame {{frame-new-token}} to provide the client
 with an address validation token that can be used to validate future
-connections.  The client may then use this token to validate future connections
-by including it in the Initial packet's header.  The client MUST NOT use the
-token provided in a Retry for future connections.
+connections.  The client includes this token in Initial packets to provide
+address validation in a future connection.  The client MUST include the
+token in all Initial packets it sends, unless a Retry replaces the token
+with a newer token. The client MUST NOT use the token provided in a Retry
+for future connections.
 

Yes, "all Initial packets" is what we want. At least it is not ambiguous. There is however a general problem with such recommendations: they are not enforced unless servers behave that way. I would add something at the end:
```
with a newer token. The client MUST NOT use the token provided in a Retry
for future connections. Servers MAY reject any Initial packet that does not
carry the expected token.
```

I am not sure about the use of the plural in "future connections". Allowing the same token to be reused in multiple connections is potentially dangerous. But that may be work for another PR.

> @@ -1614,17 +1614,19 @@ 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.  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 last used; that is, if there is a
-change in its local IP address or network interface.  A client needs to start
-the connection process over if it migrates prior to completing the handshake.
+A client SHOULD 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
+last used; that is, if there is a change in its local IP address or network
+interface.  A client needs to start the connection process over if it migrates
+prior to completing the handshake.

I assume that the text from PR #2064 will be inserted after this paragraph. Again, it is the flip side of the "client SHOULD NOT" clause. Client should not reuse the same token for multiple connections, and servers MAY (or SHOULD?) reject connections that attempt to reuse a token.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2089#pullrequestreview-180541459