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

From: Christian Huitema <[email-masked]>
Date: Sun, 30 Aug 2015 17:08:46 +0000

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?

-- Christian Huitema

---

From: Sten Carlsen <[email-masked]>
Date: Sun, 30 Aug 2015 20:11:02 +0200

> 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.
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 31 Aug 2015 14:20:04 +0000

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).

Perhaps for anonymity, it might even be appropriate to consider reducing the option set a client asks for to those it really needs (for basic connectivity). Though this might also have minimal impact, as I suspect the more bizarre option requests are typically from things that aren't usually very mobile?

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Sten Carlsen
Sent: Sunday, August 30, 2015 2:11 PM
To: Christian Huitema; [email-masked]
Subject: Re: [dhcwg] Order of options for DHCP Anonymity profile

based on the PRL).

   Request Option (ORO).

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

[email-masked]<mailto:[email-masked]>

--

Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 31 Aug 2015 20:56:52 +0200

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

---

From: Sten Carlsen <[email-masked]>
Date: Mon, 31 Aug 2015 21:07:33 +0200

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.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Christian Huitema <[email-masked]>
Date: Tue, 1 Sep 2015 01:32:44 +0000

On Monday, August 31, 2015 11:57 AM, Tomek Mrugalski wrote:
> ...

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

The draft currently does well on the first two goals -- we don't disclose identifiers beyond the MAC address, and we tested interop with a variety of servers.

The draft does an OK job at avoiding fingerprinting, if implementers just require the minimum set of options. The server may be able to find that the client is seeking anonymity, but it will have a hard time finding the client's platform.

The draft does poorly at hiding the desire for randomization, because there are some marked differences with "normal" operations, e.g., not including the host name or the vendor options. The problem there is that in order to really hide, the client would have to lie. It would have for example to manufacture a random host name that looks like something users could have set. It would have to add some vendor options. It would have to present the parameters in pretty much the same way as a "normal" implementation. 

But then, lying can very well have interop consequences, and inventing options can very well facilitate fingerprinting.

> technically true, but for all reasonably good randomizations it would require
> gathering large number of packets before you could draw any statistically
> significant conclusions.

As Bernie and Sten commented, in practice you can only do that if you use crypto-grade randomization. If you just call RAND(), then you are recognized in a single packet. But by using that type of randomization, you also signal that you are trying to hide, since your order is very different from what Windows or Android or IOS do.

> 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.

Ordering the ORO/PRL codes is trivial. In our implementation, that's just a constant list.

Ordering the actual options is harder. The code has logic like "encode the options common to all message types, then encode the options requested for this specific message."

> 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.

-- Christian Huitema