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

[Sten Carlsen <[e-mail]>]

This sounds good in my ears.

As an aside, a method to disguise yourself might be to mimic the most
common client in the current surroundings. I don't say it is easy. Just
a thought.

On 01/09/15 20:38, Christian Huitema wrote:
> 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
>
>
>
>

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"