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

[Christian Huitema <[e-mail]>]

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

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