Usage of constant value for GREASE transport parameter make quinn vulnerable to fingerprinting by quic transport parameters.

[mstyura]

Currently quinn uses constant value as GREASE reserved random parameter.

quinn/quinn-proto/src/transport_parameters.rs

Lines 303 to 305 in 9386cde

	// Add a reserved parameter to keep people on their toes
	w.write_var(31 * 5 + 27);
	w.write_var(0);

This make quinn client side users vulnerable to fingerprinting by predictable patterns during handshake. Thanks to ability to inject custom TLS backend like quinn-boring most of TLS handshake is configurable, except the content of quic transport parameters extension.

As a prevention actions I see the following steps:

1. Generate random transport parameter, like it is done quic-go or quiche]: #2057: Use randomly generated GREASE transport parameter. #2058
2. Make it optional: #2057: Option to disable sending GREASE random transport parameter. #2061
3. Implement permutation of transport parameters, like it is done in quiche: #2057: Shuffle outgoing transport parameters. #2066

[Ralith]

All three of those sound like nice improvements to me!

[mstyura]

Correct me if I'm wrong, the general philosophy of library is not to provide an API which can potentially reduce default security & privacy while providing not clear benefits. So PRs to opt out grease & random permutation (no such PR, just potentially) are not welcomed? I'm ok with any decision, just basically asking should I close above-mentioned PR or not yet (rebase).

[djc]

I think my values are that Quinn should strive to do attain optimal security/privacy by default and then we could potentially support some security/privacy-reducing choices if (a) we don't think it will have an adverse effect on future protocol development and (b) it doesn't add too much complexity. By those measures I think we could allow some limited API that opts out of grease, but maybe not random permutation? @Ralith thoughts?

[Ralith]

I'd like to additionally see some concrete motivation. The bar can be pretty low for simple features that don't take much code/documentation, but if we're adding new paths and taking up space even in documentation, I want some evidence that they're useful, ideally for multiple applications.

For example, "imitate Apple's implementation" is niche enough that I'm not sure it clears the bar. If the two proposed changes are the only necessary ones to achieve that end, then I'm ambivalent and happy to defer to @djc's opinion, bearing in mind that the behavior of another implementation will be a moving target. If more invasive changes we're unlikely to merge are additionally required, then the proposed changes don't seem to serve a purpose on their own and I'd rather do without.