Re: [dhcwg] [Privsec-program] DHCP privacy

[Stephen Farrell <[e-mail]>]

Hiya,

Most of your responses are just fine, a few responses below.

On 24/02/15 19:28, Christian Huitema wrote:
> On Tuesday, February 24, 2015, at 5:19 AM, Stephen Farrell wrote
>> To: Christian Huitema; [e-mail] Subject: Re:
>> [Privsec-program] DHCP privacy
>> 
>> 
>> And now having had a chance to read this properly:-) I still like 
>> the idea, but do have comments/questions...
>> 
>> - How does this fit with the DHC work presented in Hawaii? [1]
>> (Bear in mind I wasn't present, so the answer may be obvious to
>> those who were there.)
> 
> I will answer the questions on the DHCP mailing list. The short
> answer is that I should have referenced the problem statement drafts
> that are worked on in the DHC WG.
> 
>> - Why not try a profile for servers too or instead?
> 
> Because I believe that client profile is much more urgent. The server
> part will be covered by the general mitigation work going on in DHC.
> I guess I should change the title to make it obvious that this is
> client specific.
> 
> Also, privacy issues really only apply to mobile servers. If the
> server is static, the privacy issues are not so important.

I agree mobile servers have special privacy issues. I don't agree
that static servers don't create privacy issues for their clients.
Addressing that latter elsewhere is perhaps correct, but it needs
to not be forgotten. (So I think " privacy issues really only apply
to mobile servers" isn't correctly stated.)

> In the
> case of mobile servers, such as your phone acting as a mini Wi-Fi hot
> spot, you get a lot of protection by just implementing something like
> WPA2, effectively making the whole network private.

Well, presumably the (B|E)SSID chosen should be random-ish too. Maybe
that specific case should be in its own RFC though - folks coding
that up are probably not the usual DHCP server developer and might
need different/more guidance.

> 
>> - If the client wishes to remain anonymous (or less identified
>> perhaps) then wouldn't it be good if the client told the server
>> about that in case the server is willing to co-operate?
> 
> We can have a philosophical debate about that. If you want to be
> anonymous in the street, do you walk around with a Guy Fawkes mask?
> Or do you just dress up like the average Joe? I don't like the idea
> that anonymous users would "stick out" by putting a special option in
> their requests.

Yeah, fair enough.

> 
> Of course, there is a use case in which the server may want to
> cooperate. Suppose that an organization rents a suite in an office
> building, but does not want people on the other floors to monitor who
> is or is not in the office. They will instruct employees to use MAC
> Address Randomization on their devices. But then, they probably also
> want to control who has or has not access to the network. They could
> use for example something like 802.1x with PEAP TLS to control access
> to the network without providing observable identities in clear text.
> So now you have a private network with observable identity on the
> outside. I am not sure that the anonymity profile applies, although I
> can see how the DHCP server should be instructed to provide, for
> example, randomized IPv6 addresses.

Right. There are ways in which the DHCP server can help or hinder
in terms of making the client more or less trackable. Even if the
guidance on how to help wasn't at all normative, it might be worth
including somewhere.

> 
>> - Intro: You mention fingerprinting. I think that either deserves
>> a full section (or RFC) of it's own or else should only be
>> mentioned as not something where we're saying how to mitigate it.
>> RF fingerprinting would work ok for a DHCP server and WiFi client I
>> guess and cannot be mitigated by anything here I think.
> 
> MAC address randomization solves the trivial monitoring problem in
> which someone just uses a Wi-Fi scanner and records the MAC addresses
> seen on the air. DHCP anonymity solves the more elaborated scenario
> in which someone monitor MAC addresses and identities at the access
> point or DHCP server. If you have a good way to solve RF
> fingerprinting, I am happy to look at it. But that is a bit far from
> DHCP.

I don't have a solution no, but I think acking that nothing we're
doing here can overcome RF fingerprinting would seem right.

> 
>> - section 2, 3rd last para: shouldn't there be some relationship 
>> between the (average) random address use-time and the DHCP lease 
>> duration?  Or at least shouldn't we propose something. That is
>> tricky maybe but worth at least a mention even if only to say that
>> there is no beneficial relationship that can help here.
> 
> I realize that the draft is missing a section explaining our
> hypotheses for MAC Address Randomization. I know of several possible
> strategies:
> 
> * Draw an address at the time of connecting to a network (e.g. to
> specific Wi-Fi SSID) and keep it for the duration of the connection. 
> - Variant 1: always use the same MAC address for the same network -
> Variant 2: regularly change the address, so that a new connection to
> the same SSID may use a different MAC Address.
> 
> * Change the MAC address at regular time intervals. - On a Wi-Fi
> network, that causes a network disconnection/reconnection, and is
> thus pretty much equivalent to the variant 2 above.
> 
> In practice, there are many reasons to keep the MAC address constant
> for the time of a physical connection. Lots of annoying stuff happens
> if you change it. But yes, that should probably be explained in the
> draft.

So a stupid question: say if I use MAC-1 to get IP1 from server1
with lease1. Before lease1 is (half) over, I use a newly randomly
chosen MAC-2 to get IP2 from server1 using the same radio (say).
What'd break? What'd break that couldn't be handled via clever
client coding?

I suspect you're right that one random-MAC per e.g. WiFi session
is probably correct, but I think some more text saying that and
why might be needed. And I'm curious as to whether other options
may also work or not.

> 
>> - s2, 2nd last para: privacy "more important than" n/w mgmt isn't
>> the right way to put it I think (and would turn off a bunch of
>> folks). I think what we want is that this is something for clients
>> who care and servers who are ok that clients care.
> 
> I can change the wording to "when using the anonymity profile," and
> then add a section defining when to use it.
> 
>> - 3.1: I think you need to be clearer that you MUST NOT send this
>> just after you change MAC address.
> 
> OK.
> 
>> - 3.4 (or 3.5 or 3.6): You could create a convention here to use
>> these fields to tell the server the client wants to be less
>> identified, e.g. if the values start with "PRIVATEPLEASE" or some
>> such. (Same for some 4.x sections.)
> 
> I am really not sure about this kind of option. Reminds me of HTTP
> "Do not track" option...

Eek! But yes. If you do end up adding anything like that we should
call the flag "pretty please do not track, but I know you will" and
refer to RFC6919 :-)

> 
>> - MAC address change (and other) timing: say most clients using
>> this change MAC address and other info every 90 minutes. And say
>> that I do that at 7 minutes past the hour and you do it at 22
>> minutes past the hour. That timing could expose which of us is
>> which. I think you need some guidance on such timing.
> 
> See discussion of address change strategies. One of the reasons I
> believe the MAC should stay constant during a connected session is
> precisely that it is very easy to detect that the same client is
> reconnecting, for example because it will reestablish pretty much the
> same set of TCP connections. 

Yeah, there's an interesting study to be done there that I've not
seen I think. And a set of browser bookmarks would re-identify
pretty well too I guess, even if all are https, given SNI. However,
one problem at a time...

> So you get a lot of complexity and pain
> for not a lot of benefits.
> 
>> - section 6: shouldn't you say something about logging here? What
>> is it safe for the server to log for clients like this?
> 
> The draft is pretty much a profile for clients, so I am not sure it
> should incorporate advice for servers. But if you have text...

Nothing great but assuming there's some way for the server to
see a signal that the client would prefer to not be easily
tracked...

"Servers dealing with clients using this profile who want to
honour the client's wishes, ought minimise logging because
that may assist the client."

Cheers,
S.

> 
> 
>> On 21/02/15 01:28, Christian Huitema wrote:
>>> This might be of interest for the privacy program:
>>> 
>>> http://datatracker.ietf.org/doc/draft-huitema-dhc-anonymity-profile/
>>>
>>>
>>>
>>>
>>> 
The idea there is to plug the DHCP hole, so that devices that use MAC
>>> Address Randomization cannot be tracked through unique
>>> identifiers leaked
>> by
>>> DHCP.
>>> 
>>> 
>>> 
>>> There is similar work going on IPv6 address privacy.
>>> 
>>> 
>>> 
>>> I think of this kind of work as complementary to encryption.
>>> Encryption protects the data between device and services, but
>>> does not protect the “metadata,” such as IP addresses and other
>>> clear text headers. The most obvious pieces of such metadata are
>>> the IP addresses, the link layer addresses of wireless systems,
>>> and the DHCP information that links them.
>> But
>>> I am pretty sure that there are more sources of leakage, which I
>>> believe we should track, analyze and fix. DHCP is just a first
>>> step.
>>> 
>>> 
>>> 
>>> -- Christian Huitema
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________ Privsec-program
>>> mailing list [e-mail] 
>>> https://www.iab.org/mailman/listinfo/privsec-program
>>> 
>> 
>> _______________________________________________ Privsec-program
>> mailing list [e-mail] 
>> https://www.iab.org/mailman/listinfo/privsec-program
> 
> _______________________________________________ Privsec-program
> mailing list [e-mail] 
> https://www.iab.org/mailman/listinfo/privsec-program
>