Order transport parameters

[marten-seemann]

#3169 makes transport parameters varint. Since we’re changing the encoders / decoders anyway, this would be a good time to enforce transport parameters to be ordered by identifier.

This has the following 2 advantages:

• It (slightly) reduces the fingerprinting surface.
• It makes it trivial to enforce the property that every transport parameter is only sent once. Currently, enforcing this is just a MAY, since checking for this property might be expensive if there are many transport parameters.

[huitema]

I assume you mean ordering by TP number. I don't like that, because applications typically refer to parameters by name, not by number. For example, a plausible implementation is to have a structure holding parameters in some logical order, and code that goes through that structure and encode the parameters with only symbolic references to their TP number. Adding a sort makes the code much more complicated.

As for fingerprinting, I am not sure you can beat it with just reordering. Reordering drops the space from N! to N^2, that's better but not sufficient. The "sufficient" answer would be to create "anonymity sets", i.e. a small set of combined "profiles" specifying values or absence for all TP.

[kazuho]

My +1 goes to the proposal.

Enforcing the sender to send TPs in ascending order of TP IDs is much easier than trying to detect duplicates when TPs can arrive in any order.

Now that we've agreed to depart from TLS-based design, my preference is to fix this unnecessary complexity on the receiver side at the same time.

[marten-seemann]

I’ll prepare a PR. Still figuring out the logistical details of how to create PR against #3169, such that we can include the two changes in a single consensus call.

[larseggert]

Discussed in ZRH. Proposed resolution is to close with no action.