Subject: [quicwg/base-drafts] Order transport parameters (#3418)

From: Marten Seemann <[email-masked]>
Date: Wed, 05 Feb 2020 01:30:53 -0800

#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.

-- 
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/3418

---

From: Christian Huitema <[email-masked]>
Date: Wed, 05 Feb 2020 03:08:26 -0800

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. 

-- 
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/3418#issuecomment-582357443

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 05 Feb 2020 03:13:01 -0800

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.

-- 
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/3418#issuecomment-582359246

---

From: Marten Seemann <[email-masked]>
Date: Wed, 05 Feb 2020 03:41:00 -0800

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. 

-- 
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/3418#issuecomment-582368858

---

From: Lars Eggert <[email-masked]>
Date: Wed, 05 Feb 2020 07:40:48 -0800

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

-- 
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/3418#issuecomment-582468329