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

Sten Carlsen <> Tue, 01 September 2015 20:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C97911B4045 for <>; Tue, 1 Sep 2015 13:28:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.19
X-Spam-Status: No, score=-0.19 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Masv1T87uS5m for <>; Tue, 1 Sep 2015 13:28:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E663D1B3107 for <>; Tue, 1 Sep 2015 13:28:14 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 98012BFC80 for <>; Tue, 1 Sep 2015 22:28:05 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTPA id F279A1CCB4; Tue, 1 Sep 2015 22:28:01 +0200 (CEST)
To: Christian Huitema <>, "" <>
References: <> <> <> <> <> <> <>
From: Sten Carlsen <>
Message-ID: <>
Date: Tue, 01 Sep 2015 22:28:01 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------020202060609010404080906"
Archived-At: <>
Subject: Re: [dhcwg] Order of options for DHCP Anonymity profile
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Sep 2015 20:28:18 -0000

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: