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

Sten Carlsen <stenc@s-carlsen.dk> Sun, 30 August 2015 18:33 UTC

Return-Path: <stenc@s-carlsen.dk>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6141A1B6D for <dhcwg@ietfa.amsl.com>; Sun, 30 Aug 2015 11:33:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.59
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T32uhM_p4f5C for <dhcwg@ietfa.amsl.com>; Sun, 30 Aug 2015 11:32:58 -0700 (PDT)
Received: from mail1-hoer.fullrate.dk (mail1-hoer.fullrate.dk [90.185.2.131]) by ietfa.amsl.com (Postfix) with ESMTP id 0DADB1A036B for <dhcwg@ietf.org>; Sun, 30 Aug 2015 11:32:58 -0700 (PDT)
Received: from mail2.s-carlsen.dk (unknown [90.184.223.34]) by mail1-hoer.fullrate.dk (Postfix) with ESMTP id 1C8E5C11E6 for <dhcwg@ietf.org>; Sun, 30 Aug 2015 20:32:56 +0200 (CEST)
Received: from silver4.local (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 7AAC91C0EE; Sun, 30 Aug 2015 20:11:03 +0200 (CEST)
To: Christian Huitema <huitema@microsoft.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>
References: <DM2PR0301MB0655D1C7800B593A3C6268A1A86C0@DM2PR0301MB0655.namprd03.prod.outlook.com>
From: Sten Carlsen <stenc@s-carlsen.dk>
X-Enigmail-Draft-Status: N1110
Message-ID: <55E34736.60609@s-carlsen.dk>
Date: Sun, 30 Aug 2015 20:11:02 +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: <DM2PR0301MB0655D1C7800B593A3C6268A1A86C0@DM2PR0301MB0655.namprd03.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------050508000001060002060100"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/5GWTn6dRC5f2lu6-pwu0d9BxNUQ>
Subject: Re: [dhcwg] Order of options for DHCP Anonymity profile
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Aug 2015 18:33:01 -0000


On 30/08/15 19:08, Christian Huitema wrote:
> In his review of the anonymity profile, Bernie suggested considering the order of options and the PRL parameter of DHCPv4:
>
>> BV> New section between 3.4 and 3.5 to include the PRL similar to ORO text in
>> 3.5? Kind of odd that the Parameter Request List isn't mentioned at all for
>> DHCPv4 where there exists a fairly extensive fingerprinting database (mostly
>> based on the PRL).
> I am looking at the current text in the draft, and the DHCPv6 paragraph reads:
>
>    One specific method used for fingerprinting utilizes the order in
>    which options are included in the message.  Another related technique
>    utilizes the order in which option codes are included in an Option
>    Request Option (ORO).
>
>    The client willing to protect its privacy SHOULD randomize options
>    order before sending any DHCPv6 message.  Such a client SHOULD also
>    randomly shuffle the option codes order in ORO.
>
> We could add similar text in the DHCPv4 section, but I have a small question regarding practicality of "randomizing the options." The current code is simple and static, with different blocks processing different related options. Randomization would require either executing the code blocks in random order, which is tricky, or adding a post processing phase to shuffle components of the messages, which is not natural.
>
> As far as the ORO or PRL options are concerned, I would suggest that requested option numbers be sorted from smaller to larger. That allows for static implementations, and defeats fingerprinting just as well as randomization.
>
> For the ordering of the actual options, I don't think that requiring randomized order is practical, and I would prefer allowing implementers to use a static order.
>
> Any advice from the WG?
This is a tricky issue. There are several paths, each with its perils:
- some devices on the network randomises, some don't - this highlights
who wants to be anonymous.
- the randomisation function might be recognisable, yielding another
fingerprint.
- the collection of what you ask for is still a good part of a
fingerprint regardless of sequence.

The most anonymous approach would probably be that each device asks for
the exact same things in the exact same order all over the world. This
is obviously not going to happen.

Just my 0.02$
>
> -- Christian Huitema
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"