Re: [dhcwg] Order of options for DHCP Anonymity profile

[Christian Huitema <[e-mail]>]

On Tuesday, September 1, 2015 12:09 AM, Sten Carlsen wrote:

> On 01/09/15 03:32, Christian Huitema wrote:
>> On Monday, August 31, 2015 11:57 AM, Tomek Mrugalski wrote:
>> ...
>>> On 31.08.2015 16:20, Bernie Volz (volz) wrote:
>>>> Ordering by option number seems a fine (and simpler) approach. The
>>>> differences in options requested might still make fingerprinting
>>>> possible (especially for clients that ask for more unusual options).
>>>
>>> By sending options ordered you would disclose the desire for anonymity.
>>> It is obvious from the first packet intercepted.
>>
>> We have four goals:
>>
>>  * don't break stuff, don't do something that will cause interop issues.
>>
>>  * hide the identity of the device and the user. I think we achieve that.
>>
>>  * escape software fingerprinting, avoid identifying the platform being used.
>>
>>  * hide the fact that we are using randomization
>>
> I think the first two goals are achievable, I doubt the last two are. We probably do the best possible with > reasonable effort, maybe hiding as one in the crowd is just as effective.

Let's try for as much uniformity as we can, it will not hurt.

> ...
>>> I still think that randomizing the order of both options and option codes in
>>> PRL/ORO is the way to go. If you strongly object to that, perhaps the text could
>>> say that the client SHOULD randomize, but if it's not possible for whatever
>>> reason, it MAY send options/option codes ordered by option number.
>>
>> I could live with that if that enables consensus.

I have a version of the draft with this SHOULD/MAY text, but it is awkward. I think that's because we are conflating two issues: the general problem of fingerprinting, and the specific problem of the ORO/PRL parameters.

I think we need to move the text about option ordering to a separate section on "avoiding fingerprinting," and not leave it as a side note in the formatting of ORO/PRL. 

I can think of three types of data for fingerprinting: the choice of options in the message; the order of these options; and the choice of option values. The current draft largely specifies the choice of options and the option values, with a subsection for each option type. The new "fingerprinting" subsection would carry the text about ordering of options in the message. 

The ORO/PRL section should be strictly about ORO/PRL option content. There are two issues there: which parameters to request, and in what order. In our implementation, we chose to request exactly the same parameters in "anonymous" and "normal" mode. In both cases, the ORO/PRL content is ordered by increasing code numbers. There are pros and cons:

* Using the same parameters definitely allows for fingerprinting as "windows 10 client." We include codes like NetBios name server option that are definitely Windows specific.

* Using the same parameters makes the anonymous profile similar to normal use, and thus hides the fact that the client is trying to remain anonymous.

* Using the same parameters minimizes the risk that we are causing some kind of regression with the anonymous profile change.

As I said, I am happy as long as we have an option to allow our current behavior.

-- Christian Huitema