Re: [quicwg/base-drafts] Authenticating connection IDs (#3439)

[Antoine Delignat-Lavaud <[e-mail]>]

> If the client needs similar assurances it cannot use th AAT directly to do its own checking, but philosophically, the server decides the CIDs going towards the server, and it is the servers responsible to design and check those CIDs with reasonable security bounds for the given deployment. If a server does not check for retry attack CIDs, there are many other things that it might also not check making the connection flawed in some way.

I disagree, there are not many other things that the client and server can disagree on after the end of the TLS handshake. The idea to consider connection IDs as an unauthenticated connection parameter (just like the IP address and UDP port) that can be used by networking middlebox for DoS/routing is fine, and it's a possible way to close this discussion, but I urge you to carefully consider the privacy impact for the client. It is somewhat pointless to write a formal proof of packet number encryption if it turns out that an active adversary can inject a 20-byte long unique identifier that appears in the cleartext of every packet - imagine if China starts doing that to tag incoming QUIC connections to users, if many servers allow them to (expecting their own middleboxes to do the same thing for legitimate reasons). Of course it is already possible to do that with TCP, but QUIC CIDs are much longer than TCP ports and can be use for pervasive monitoring at a fine granularity. If CIDs are truly negotiated between the client and server, the client has the guarantee that the server CID really comes from the server, and knows that no tracking CID has been inserted on the way. 

-- 
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/issues/3439#issuecomment-595702363