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

Sten Carlsen <> Mon, 31 August 2015 19:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 12AC71B4FBB for <>; Mon, 31 Aug 2015 12:07:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.59
X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zMnFptQhFyMb for <>; Mon, 31 Aug 2015 12:07:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 11ED71B4CCE for <>; Mon, 31 Aug 2015 12:07:38 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 45C0DC10C2 for <>; Mon, 31 Aug 2015 21:07:36 +0200 (CEST)
Received: from silver4.local (unknown []) by (Postfix) with ESMTPA id 5A31A1C116 for <>; Mon, 31 Aug 2015 21:07:34 +0200 (CEST)
References: <> <> <> <>
From: Sten Carlsen <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Mon, 31 Aug 2015 21:07:33 +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="------------070108010008000409050704"
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: Mon, 31 Aug 2015 19:07:46 -0000

I don't quite agree, reshuffling or specifically ordering options both
indicate you want to hide, that alone attracts interest, so maybe the
best thing is to not be different from others?

If the tracker has a copy of the randomisation function, usually just a
few samples will suffice to identify both the function and the position
of the sequence. As comparison, keys for cars with remote control use a
32bit pseudo random number for protection and two consecutive captures
are enough to predict the next number (and steal the car).

I wish I had the answer, all I have are some questions.

On 31/08/15 20:56, 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.
> Sten said that the randomization function might be recognizable. That's
> technically true, but for all reasonably good randomizations it would
> require gathering large number of packets before you could draw any
> statistically significant conclusions.
> Christian said that the order of options comes from how the software
> processes the packet. I understand that. But I think the conclusion
> coming out of it is somewhat weak. You say that it's doable to order
> options by option code but it's too much effort to randomly reshuffle
> them? In both cases that would likely be a step conducted at the final
> steps of packet processing, shortly before sending it over the wire.
> 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.
> Tomek
> _______________________________________________
> dhcwg mailing list

Best regards

Sten Carlsen

No improvements come from shouting: