clarify the scope of a NEW_TOKEN token

[kazuho]

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.

Closes #3155.

[mikkelfj]

What happens if it does anyway?

[kazuho]

We have a normative text below that says: if the token is invalid then the server SHOULD proceed as if the client did not have a validated address, including potentially sending a Retry.

[mikkelfj]

I think it needs to be clarified that at a client 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.

EDIT: I wrote a "a token SHOULD not include a token" but meant "a client SHOULD not include a token"

[kazuho]

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.

I am not sure if I follow your logic. This is a privacy concern. What we want to prohibit is the client sending a token to a different server identity, not the server using the token.

[mikkelfj]

OK, then I have misunderstood this. Unless covered in neighbouring paragraphs I think this should be explained.

However, if the token is required to appear random and unique, why would there a privacy concern? Due to length, or because appear random is not a realistic requirement?

[kazuho]

The privacy concern is being discussed in the issue, starting from #3155 (comment).

[mikkelfj]

I see thanks, even I participated in that, too many things going on I guess.

[ekr]

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"?

[mikkelfj]

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.

[kazuho]

@ekr Quoting from RFC 8446 section 4.6.1, the requirement for NST is:

   Clients MUST only resume if the new SNI value is valid for the server
   certificate presented in the original session and SHOULD only resume
   if the SNI value matches the one used in the original session.

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.