On Wed, May 28, 2025 at 6:32 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> I'd not think being able to fingerprint an implementation > implies a total loss of user privacy, which is how I read > the above. > > What am I missing? > Not a total loss of privacy. Just the ability to detect which implementation initiated this connection. That's what I understood MT's goal to be. On Wed, May 28, 2025 at 6:42 PM Christian Huitema <huit...@huitema.net> wrote: > It is not really about implementation. It is about configuration, from > which the DPI wants to deduce "is this connection going to receive > videos". They do that today looking at the SNI, but I assume that they > will do it tomorrow by looking at which QUIC extensions you negotiate, > or whether your initial parameter values resemble something that MoQ > uses, etc. > In the context of browsers, a single configuration is used across all websites. (There might be some minor differences based on what you got in the HTTPS RR, but not for us since we don't support QUICv2.) You're right in the context of apps though. The YouTube and Google Search apps use the same QUIC implementation but with different configurations. I still think that the total search space is sufficiently small here that it doesn't make a real difference. Maybe, but the transport parameters are much worse than the DCID length. > Absolutely true. But I'm not sure this is enough to prevent implementation/configuration fingerprinting. That's kinda why I am looking for a "default TP" profile. If we chose > the default well, it can coincide with regular H3 over QUIC, and so the > "real" ECH will not look different from H3+Grease. I don't think a "default TP" profile is workable in practice. Google's implementation sends custom transport parameters to indicate what experiments it's running. Some are public, like delayed ACK, and some are proprietary. But fundamentally, if there is no ECH config, we'll still want these transport parameters to be communicated to the server. As another example, I don't expect anyone using MPQUIC to only use it when ECH is enabled. Since transport parameters are our ~only extension joint, it needs to work even when there is no ECH config. If we really wanted to solve this problem, I would instead solve it by adding a TLS EncryptedExtensions message in the client-to-server direction that is sent under handshake encryption as part of the client's second flight, and allowing transport parameters to be sent there. Most transport parameters aren't needed until then anyway. David
