#2057: Option to disable sending GREASE random transport parameter.

[mstyura]

As a step toward reducing surface to fingerprint quinn connections I propose to introduce option to disable sending GREASE transport parameter.

[djc]

As a step toward reducing surface to fingerprint quinn connections I propose to introduce option to disable sending GREASE transport parameter.

What exactly is the motivation here? It seems like randomized GREASE would increase fingerprinting here, which seems at odds with your goal? Or are you trying to mimic other tools that don't send GREASE?

(Context in #2057.)

[mstyura]

The presence of GREASE at specific position is itself may be used to fingerprint connection (client application in my case, not an individual user), so I wanted to have an option to omit it. I supposed that this change (Make it optional) was "pre-approved" by comment and like on it in context of the issue https://github.com/quinn-rs/quinn/issues/2057.

It seems like randomized GREASE would increase fingerprinting here, which seems at odds with your goal?

The randomised GREASE is used by browsers (Chromium, Firefox), so it's value can not be used to fingerprint user. But the positions and the presence of parameters could be used as one of the fingerprinting methods of an application.

Or are you trying to mimic other tools that don't send GREASE?

Ideally I'd like to have more control over transport parameters handshake including order of parameters, their presence and values.

To be honests, I'd like to eventually mimic quic handshake of Apple's UrlSession to make quinn connections indistinguishable from Apple's.

I understand that upstream quinn may not need that level of flexibility (especially regarding values of some transport parameters like min_ack_delay or active_connection_id_limit), but this specific case seems to be generally useful for others - so I decided to send patch to upstream.

[Ralith]

Making Quinn harder to fingerprint is great, but I'm not sure if it makes sense for us to invest in the capability to pretend to be a specific other implementation. Esoteric configuration like this can also be difficult for downstream code to use correctly, and don't reduce fingerprinting when unused. Instead, we should work to be difficult to fingerprint by default, without any configuration required.

Would it make sense to omit the grease parameter based on random chance instead?

[mstyura]

Making Quinn harder to fingerprint is great, but I'm not sure if it makes sense for us to invest in the capability to pretend to be a specific other implementation.

I agree with the statement. There is no sense in making Quinn mimic other implementations. It supports features that may not be supported by others, and vice versa. Mimicking other/any QUIC implementation is not the purpose of this library, unlike specialized libraries such as uTLS. So, I don't expect, for example, an API to inject something like goog* parameters into the handshake to mimic the YouTube app or anything crazy like that.

I consider Quinn a general-purpose, easy-to-use QUIC implementation with a great level of flexibility. I expect a general-purpose library to have the ability to opt in and out of default behaviors when it's doable in a sane way/API. And Quinn already does flexibility really well—features like replacing crypto, injecting custom packet transport, and providing custom congestion controllers all allow customizing Quinn enough to overcome unusual environment issues like running on mobile or specific requirements like crypto should be boringssl. So, having the ability to omit the GREASE transport parameter felt like a natural follow-up to the PR where it was implemented.

Would it make sense to omit the grease parameter based on random chance instead?

That can be an option, I think. The question is, what probability should it have by default? Should the user of the library be allowed to adjust it? Basically, setting it to 0 or 1 would make it work as an on/off switch, while allowing values between 0 and 1 enables even more flexible behavior.

Instead, we should work to be difficult to fingerprint by default, without any configuration required.

Can't agree more with this. So, let's maybe put this PR on hold for a while before it's finally rejected or decided to be changed to include the GREASE transport parameter probabilistically by default.

I've noted in the original issue that I think transport parameters should be randomly permuted by default when sent on the wire to make fingerprinting harder.
This seems much more valuable (compared to the change from this PR) and a major improvement to make Quinn less likely to be fingerprinted.

Please let me know if you would be open to accepting such changes in another PR with random permutation of QUIC transport parameters implemented.
I understand that if you are open to such changes, it will require several rounds of review and discussion until it meets the quality requirements to be accepted.

[Ralith]

Yes, permuting the order of transport parameters is absolutely something I've been wanting for a while. I think it's generally understood among implementers to be the preferred strategy, even just for anti-ossification. Thanks for working on it!