Re: [dhcwg] Hostname randomization issue in draft-ietf-dhc-anonymity-profile-00.txt

Christian:

I think the reason for this was that this assumed that the mac address was also a 'privacy' address. But you are correct that this may not be as wise an idea because this could potentially publish this mac-address in the global DNS.

I wonder whether just leaving out the host name option would be best. If a server wanted to assign a name, it could always generate it itself using some technique (such as an ASCII form of the assigned IP address)? RFC 4702 (DHCPv4 FQDN) and 4704 (DHCPv6 FQDN) allow the client to leave the domain name field empty (if the client desires the server to provide a name).

- Bernie

-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Christian Huitema
Sent: Friday, May 22, 2015 2:51 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Hostname randomization issue in draft-ietf-dhc-anonymity-profile-00.txt

Reviewing that document, we found a small issue in section 3.5, "hostname option". The text says:

   When obfuscating the host name, DHCP clients SHOULD set the host name
   value to a hexadecimal representation of the link layer address that
   will be used in the underlying connection.  They MAY choose another
   convention in rare cases, for example in multi-homed scenarios.

It turns out that sending an hexadecimal representation of the MAC address is a potential privacy leak. Some DHCP servers will publish the client name in the DNS. Third parties can then read that name, and retrieve the MAC address. It is probably better to use a random value. For example, the DHCP client could compute the hash of the MAC address and a local secret, and then publish an ASCII representation of the first 48 or 64 bits of that hash.

-- Christian Huitema

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg