Re: [quicwg/base-drafts] clarify the scope of a NEW_TOKEN token (#3156)

[MikkelFJ <[e-mail]>]

mikkelfj commented on this pull request.



> @@ -1698,10 +1698,15 @@ encrypted form in the token.
 It is unlikely that the client port number is the same on two different
 connections; validating the port is therefore unlikely to be successful.
 
-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 SHOULD include that value in the
-Token field of its Initial packet.  Including a token might allow the server to
-validate the client address without an additional round trip.
+A token received in a NEW_TOKEN frame is applicable to any server that the
+connection is considered authoritative for (e.g., server names included in the
+certificate).  When connecting to a server for which the client retains an
+applicable and unused token, it SHOULD include that token in the Token field of
+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.
 

I think it needs to be clarified that at a token SHOULD not include a token instead of MUST not. It is easy to imagine cases where the client has a strong belief, which is ultimately wrong. Having a MUST here is too strong a burden to place on the client which does not construct the token. Rather, a server MUST not accept a token that a client incorrect submits.

-- 
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/3156#pullrequestreview-316789676