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

From: Sten Carlsen <[email-masked]>
Date: Tue, 1 Sep 2015 09:08:31 +0200

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.
>
> 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.
>
>> 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.
> 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
>
>
> _______________________________________________
> 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: Christian Huitema <[email-masked]>
Date: Tue, 1 Sep 2015 18:38:33 +0000

On Tuesday, September 1, 2015 12:09 AM, Sten Carlsen wrote:

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

---

From: Sten Carlsen <[email-masked]>
Date: Tue, 1 Sep 2015 22:28:01 +0200

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.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"