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

[Kazuho Oku <[e-mail]>]

kazuho commented on this pull request.



> @@ -1698,10 +1698,14 @@ 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 against the servers that the
+connection is considered authoritative for (e.g., server names included in the
+certificate).  A client MUST only use a token that is applicable to the server

@martinthomson FWIW I think the attack you were discussing was something different, that works even if the tokens were perfectly encrypted.

Consider the case where an attacker is an ISP and also controls example.com, which is hosted behind the large-scale load balancer hosted by a different entity (e.g., CDN). The attacker issues tokens when clients connect to example.com through the load balancer (IP address 192.0.2.1). Then, when the clients connect to different hostnames under the same load balancer (IP address 192.0.2.1), it can (as an ISP) see which exact clients went for which exact server-names.

I think you pointing out this attack has effectively killed https://datatracker.ietf.org/doc/draft-kazuho-quic-address-bound-token/, I appreciate that. But if it is the case that you think it's an attack we can ignore, I'm happy to revive the draft :-)

-- 
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#discussion_r339530240