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

Christian Huitema <> Tue, 01 September 2015 18:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C5C8F1A6FEF for <>; Tue, 1 Sep 2015 11:38:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xXToOInuq4Kc for <>; Tue, 1 Sep 2015 11:38:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 159631A6FB5 for <>; Tue, 1 Sep 2015 11:38:36 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 1 Sep 2015 18:38:34 +0000
Received: from ([]) by ([]) with mapi id 15.01.0256.013; Tue, 1 Sep 2015 18:38:34 +0000
From: Christian Huitema <>
To: Sten Carlsen <>, "" <>
Thread-Topic: [dhcwg] Order of options for DHCP Anonymity profile
Thread-Index: AdDjQ5/X5uFde6IFSve9jsTqSE4nXQAC5rUAACo5mQAACarJAAAM8HvgAAyc+4AAFxk4wA==
Date: Tue, 01 Sep 2015 18:38:33 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:4898:80e8:7::6f]
x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 5:TH0gaGZ0HCnqOWY3WQprOauJOaMGDMSo/fEBrss1Su3eq/dAzNw+Hb6Nt8olSch6EfVnyw+VbqeJmS2a2sIFyXZtS3bfYeo0JCPkOmmwbtWGNpghGdmpyJ1Wv/jW63Bf/ZZH5SdLw1el0/kv2eFyxQ==; 24:b5KU83s0Gx88MvJyYgRa8LGCdwEPclrh1J/7UtceWkhsRu0Vt4S1Q7Eg+NI9On3ulTYqh8pl7iDpKFtkK8T/uu9D57PuqwgHUSFypdBRBxI=; 20:jUszqhGQ7ggwajFdtk9O0uc97klEIqLI7wi7pkMYa9Lq7mPim3geC50gCeXwAklhPQtUBK0tL2M3Gy0uLR6pmQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(8121501046)(3002001); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653;
x-forefront-prvs: 06860EDC7B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(24454002)(479174004)(51444003)(377454003)(199003)(2501003)(76576001)(5001860100001)(5001770100001)(5005710100001)(40100003)(5002640100001)(10090500001)(10290500002)(5001960100002)(5007970100001)(93886004)(5004730100002)(102836002)(33656002)(99286002)(46102003)(2656002)(68736005)(106356001)(10400500002)(122556002)(105586002)(64706001)(2950100001)(50986999)(189998001)(86362001)(77096005)(76176999)(77156002)(107886002)(101416001)(97736004)(5003600100002)(92566002)(5001920100001)(62966003)(4001540100001)(81156007)(86612001)(5001830100001)(54356999)(8990500004)(87936001)(2900100001)(74316001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2015 18:38:33.8573 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653
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 18:38:38 -0000

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