Change:
different connections; validating the port is therefore unlikely to be successful. <del> 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. </del> <ins> 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. </ins> Including a token might allow the server to validate the client <del> address without an additional round trip. </del> <ins> 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. </ins> A token allows a server to correlate activity between the connection where the token was issued and any connection where it is used.

Discussion:
This PR clarifies that the scope of a NEW_TOKEN is equivalent to that of the TLS connection (i.e., the scope of the server certificate), in a minimalistic way.
I'm not sure that this is the right scoping. Consider that NST is explicitly tied just to the server you connected to, not to any server found in the certificate. Why isn't this "same server name"?
Retry is a server controlled method that can be used for various things including client address validation, but also load balancing or redirects to a more local or somehow better service. Requiring these alternative locations to be tightly coupled to the original connection would work against this.
NAME Quoting from , the requirement for NST is: MUST NOT added in this PR achieves parity with the "MUST only" statement in TLS 1.3. Regarding the SHOULD in TLS 1.3, I do not think we need feature parity. Compared to TLS 1.3 running over TCP, it is extremely difficult in QUIC to create a proxy that extracts the SNI and then let's different backend server handle the connection. It is natural to assume that a QUIC server that presents a wildcard certificate to be directly hosting all those server identities.
At the moment, states that a resumption token can be used "if the client has a token received in a NEWTOKEN frame on a previous connection to what it believes to be the same server._" But what does "the same server" actually mean? Some possible answers include: a) the same server IP address b) the same server IP address and port c) any server name that was presented in the certificate provided in the previous connection (the scope of session tickets; see ) d) the same server-name e) the same server-name and ALPN (the scope of 0-RTT; see ) I'd presume it to be one of a, b, or c, but I think it'd be better to clarify what "the same server" actually means.
IIRC, NAME pointed out that the scope of tokens should be as tight as that of the session tickets (i.e. option c), due to the following reason. Consider the case of a split-server deployment (i.e. a gateway with a single IP address mapping connections to different QUIC servers in the backend, based on SNI).

If we are to adopt option a or option b, one of those backend servers might issue a token, that would then be used by the client when connecting to a different backend server that shares the same gateway. This means that the party controlling the server that issued the token can see that the same client connected to a different server, assuming that the party can observe the traffic that goes into the load balancer. To avoid the leak, the scope of NEW_TOKEN tokens should be at least as tight as the set of the server-names that the issuer of the token is authoritative for; which means option c.
is an attempt to clarify option c being the choice.
I agree that a or b is not restrictive enough based on the example given above. I wonder if c/d/e are also not restrictive enough though. Consider URL hosted on multiple CDNs (where QUIC is terminated by the CDN). A client makes an initial connection to URL (which gets served by CDN A) and receives a NEW_TOKEN token. Later, this client looks up URL, gets directed to CDN B, and sends the token it received on the connection to CDN A. I wouldn't expect CDN B to be able to process that token. We could also decide that it's not worth solving the case above. Being overly restrictive in scoping tokens could mean we don't save tokens often enough (resulting in connections being established with no token when we could have used a token), which might be worse than occasionally sending the wrong token to a server.
NAME I think that is a performance concern rather than a security concern? Assuming that it is the case where sending a token does not have any positive impact on performance, I think we might not need to care about that. We could, but I think it would be hard to draw a line on when sending a NEW_TOKEN token can be considered beneficial enough..., and there is no negative performance impact on sending an unusable token.
Agreed, it's a performance concern, not a security concern. If the client sends an unreadable token, worst case is the server sends a Retry packet and we burn a round trip.
FWIW, the discussion here relates to issue (PR ). If we are to say that the scope of a token is tied to the identity of the server (i.e.

server certificate), it becomes impractical to use token-based greasing for hosts that are hosted by multiple entities (i.e. multi-CDN use-case). This is because owners of such hosts would not want to see an additional round-trip due to Version Negotiation packet being sent in response to an unknown version. If we are to say that the scope of a token is a tuple of the server identity and the server address, maybe that becomes an non-issue, as we can assume that the tuple uniquely identifies the operator of the server.
I think that is good enough. There are lots of ways to slice this and what is proposed there seems like the most tractable. I'm sure that it's not perfect, but I don't think that there will be a perfect answer here.
As I wrote in URL I think there is an aspect of certificate privacy where you can reconnect with a different server certificate after you obtain a secret salt. Making "same server" too narrow would prevent the privacy benefits of such an approach.` Publishing a link between such certificates would kind of defeat the point, so there is a chicken/egg problem here. However, if the client has out of band knowledge of another domain that works, it should be allowed to use it.
NAME I think I tend to agree with this statement. And aside from the privacy benefits, I'd note that there is a performance benefit that I am interested in (i.e. URL). As an example, it would be safe to say that servers sharing the ESNI keys are covered by a single token, considering the fact that ESNI keys is assumed to be retained by a single authority that can decrypt the Initial packet payload.
I see a lot of value in alternative "a or c" for CDNs. The purpose of the token is to prove to the server that the client owns the address. It should not matter why the client received the token (similar to TFO token). As for the privacy, I do not see a problem. The gateway already sees everything and knows everything. If the backends cooperate, they already know everything. If they do not cooperate, this is no different than a multi-CDN case.
NAME Only when the gateway is encrypting / decrypting the traffic. Counterexample is QUIC-LB, where the gateway just forwards the packets to different backend servers.

(c) is exactly the same as what we state for TLS session tickets in RFC 1.3, which covers the multi-CDN case. If we want to be more lax, I think we need to present that there is no privacy concerns in doing so.
NAME If gateway does not have the keys, it has no more info than a multi-CDN case. In fact, it has less info -- it cannot tell when the new connection is for the same or different hostname than the one that issued the token. I am interested in anyone presenting a material reduction in privacy in case (a) that is absent in a multi-CDN case with case (c). (I am not aware of a way to prove lack of privacy concerns other than making an attempt to find some and falling to do so).
NAME How about URL
NAME I did see this but am confused where the risk is. If a party can see all traffic going to a specific IP, is the concern that it is giving them some extra information when there are multiple clients behind a NAT?
NAME No. The concern is on the server-side, where three parties are involved: a) owner of LB (that only sees unencrypted traffic), b) owner of one server behing a, c) owner of another backend server behind a, who can also monitor the traffic between clients and a. The attack goes like this: c accepts a connection from a legitimate client (through a), and issues a NEWTOKEN token The client reconnects to b (through a), using the the token obtained in step 1. At this point, c can tell that who connected to b. Going back to our design principle; we require NEWTOKEN tokens (and also TLS session tickets) to be sent using an encrypted channel, and to be used only once, because the fact that the client is connecting to a particular server should not be exposed to a third party. In this example, we are violating that requirement.
NAME So why is the answer to my question of whether the scheme above gives out extra information only in case of multiple users behind a NAT: no? If there is only a single user behind an IP, a party that can observe all traffic to load balancer "a" can know who is connecting to "c" and "b" just by matching on the src ip and seeing that they are the same.

NAME I think the hidden assumption in your argument is that the client is connecting to "b" and "c" at the same time. When that assumption is met, I think you are correct that the attack is only viable when the client is behind a NAT. But it could also be the case that the client first connects to "c", disconnects, then connect to "b" using the token obtained from "c" from a different address. In that case, the attack becomes concerning even when the client is not behind a NAT.
NAME This is an address validation token. It is coded for a particular client address. The client will not use the token if it has migrated to a different address. This is very similar to TFO Cookie handling.
The specification is not written as such. Section 8.1.2 states, that if the client has a token received in a NEWTOKEN 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. There is no requirement for the client to check it's address (or the network). I think that the approach used by the specification is correct. In practice, I think we cannot assume that all the clients would correctly deal with their source address explicitly (as well as the change of the address). Besides, a change of source address does not necessarily mean that the client has migrated to a different network. Consider the case where a client goes out of one DHCP network, then returns to that network. In such case, the client might receive a different address, but it is still on the same network. After all, we are requiring the server to associate NEWTOKEN tokens and the original source address. Then, why not let the server decide if a token can be reused?
For the client, the consequences of a bad guess is a wasted token and (maybe) the wasted bytes. That's all. So in general, there is no reason to constrain use of tokens where the client thinks that they might be useful AND that the client is willing to risk linkability between sessions. The latter condition is where the various linkages come into play, but the point remains that the client is responsible for making an assessment. This text is about setting a common baseline for that.

If a client wants to extend the set of servers that might be able to link sessions, I think that's OK, but it has to do this on the understanding of what that means. The server that issued the token might see this new usage and link it to a specific prior context. Without ESNI, that means things like knowing where previous users are now trying to connect. As NAME says, a client might choose to constrain token use to particular networks, but it doesn't have to. I might even go so far as to say that they should probably not reuse a token from a different network location, but that depends on having information that I know is hard to acquire. A requirement that the token only be used from a certain network location wouldn't be implemented because in some cases it couldn't be implemented reliably.
I think it is a good thing to cover multiple networks because you can hide from external observers. But, if you are on a corporate or government MITM proxy matters are only going to get worse. That said, QUIC cannot possibly accommodate deliberately broken networks. Also, clients have interests adverse to users as well - for example Google and Facebook need qualified advertising traffic and if QUIC tokens can slip under the Cookie radar, they will. I can't manage a Google cloud cluster without logging in to Youtube on an account that has never signed up for Youtube, and now I can't watch cat videos without getting cluster management commercials which really goes against the point of watching cat videos in the first place (or something roughly equivalent), so on. So, there is tension in how much to leave for the client to decide vs actual user privacy.
NAME NAME Indeed, that's correct, no requirement to check address/network on first use. There is language about reuse that does require the check (but the reuse itself is not required / actually discouraged): "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." I think I can live with the new language, since it gives clients enough flexibility in case they believe that the server that issued the token and the new server cooperate in managing the tokens (including a belief that they are the same server). So no objection to the current language in on my part.