[3xblah]

"The source-address token is a unique, authenticated-encrypted data block provided by the server, which cannot be decrypted by the client. For the purpose of IP address spoofing prevention, it contains the users publicly visible IP address and a timestamp as seen by the server."

Compare ...

http://curvecp.org/security.html

"Does CurveCP provide client address authentication?

No. IP addresses are not secure in any meaningful sense, and CurveCP does not attempt to make them secure. Servers that distinguish between clients must do so on the basis of long-term client public keys, not IP addresses."

Users can create new public keys anytime they want. They could, e.g., create one key for one purpose and another for another purpose. Over the years, I have noticed a common theme in the design of all djb software. Whether it is intentional or not, I do not know. Control rests with the user.

[tialaramex]

So, I think you've completely misunderstood what's going on here.

What QUIC is doing here is to prevent _spoofing_, whereas what DJB is talking about is the futility of using IP addresses as _identity_

Why does this matter? QUIC servers often have lots of bandwidth available to them and offer 0-RTT, so they can be used for an amplified denial-of-service attack. Bad Guys send packets "from" your IP address to the QUIC server. Without spoofing protection the QUIC server begins bombarding your IP address with stuff. Your network links saturate and you're effectively knocked out even though you did nothing to cause this.

Spoofing protection is provided in TCP (on any vaguely modern OS) but QUIC doesn't use TCP so it must roll its own protection and that's all this is for.

CurveCP has a 1-RTT setup penalty with a "Cookie" to prevent spoofing. If somebody wants to track you with CurveCP they'd be just as able to use this cookie as they would the QUIC "source address token". In both cases you could throw this away to prevent tracking, at a penalty of reducing performance because you'll have to do the startup dance all over again.

[3xblah]

The paper discusses how source address token might be used in tracking and thus online advertising services, Google's business.

The online tracking and advertising industry and companies selling to that industry such as Google believe IP addresses, when combined with other information, tell something valuable about consumers.

Perhaps users of the "modern web browsers" cannot or will not manually control generation or storage of source address tokens. Hence the need for papers like this one, pleading with the organisations controlling the browsers to change the software. That software is of course written by employees of companies and parents of companies that are paid directly or indirectly from sales of internet advertising services.

Probably the folks creating these protocols never thought about the implications of the design on internet advertising services. However, from the perspective of people selling internet advertising services, the association/non-association of IP addresses with public keys seems like it might be significant, regardless of its intended purpose to the protocol designers. People buying those online ad services are likely to understand the potential value of IP address information, e.g., they might think it tells them something about geo-location. If so, they might also see the added value in the combination of IP address with a unique identifier.

[3xblah]

"If somebody wants to track you with CurveCP they'd be just as able to use this cookie as they would the QUIC "source address token"."

https://curvecp.org/confidentiality.html

"Two minutes after a connection is closed, the server is unable to extract the client's long-term public key from the network packets that were sent to that server, and is unable to verify the client's long-term public key from the network packets."

"The second packet from the client contains a cookie from the server. This cookie is actually a cryptographic box that can be understood only by a "minute key" in the server. Two minutes later the server has discarded this key and is unable to extract any information from the cookie."

By contrast, the paper suggests QUIC source address tokens have no expiration and are retained for a minimum of 11 days by the existing QUIC-compatible browsers.

https://curvecp.org/packets.html

"Server Cookie packet details A Cookie packet is a 200-byte packet with the following format:

8 bytes: the ASCII bytes "RL3aNMXK".

16 bytes: the client's extension.

16 bytes: the server's extension.

16 bytes: a server-selected compressed nonce in little-endian form. This compressed nonce is implicitly prefixed by "CurveCPK" to form a 24-byte nonce.

144 bytes: a cryptographic box encrypted and authenticated to the client's short-term public key C' from the server's long-term public key S using this 24-byte nonce. The 128-byte plaintext inside the box has the following contents:

32 bytes: the server's short-term public key S'.

96 bytes: the server's cookie."

It appears CurveCP's two minute server cookie lacks any easily usable tracking information. There is no client IP address, no long-term client public key, no long-term server public key.

In contrast, the paper suggests QUIC's evergreen source address token containing the client IP address is intended to be reused in subsequent connections and can be easily used for tracking:

"The client caches the source address token and presents it to the server during the setup of a new connection. This allows a server to link the connection where the source-address token is initially issued with each subsequent connections where the same token is presented during the CHLO message. Finally, this enables the server to identify a chain of connections associated with a user."