This is a discussion on Re: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs - DNS ; On Tuesday 07 February 2006 18:04, Bernie Volz (volz) wrote:
> I also don't recall the history (because I either wasn't involved or was
> fairly disinterested at the time) the reason for encoding this, but suspect
> it was ...

On Tuesday 07 February 2006 18:04, Bernie Volz (volz) wrote:
> I also don't recall the history (because I either wasn't involved or was
> fairly disinterested at the time) the reason for encoding this, but suspect
> it was to make it somewhat difficult for someone to find the client's
> identity and potentially track the user through the Internet as they
> connect to different access networks (assuming the DHCID RR was available).
> I don't believe the goal was ever to make it impossible, just somewhat
> difficult so that most folks wouldn't bother.

The original motivation for using MD5 was to protect the privacy of the client
by not publishing its client identifier (typically the MAC address of the
ethernet card) in the DNS. But we're already publishing the client's
identity in the DNS in the form of the hostname it sends to the server.

So someone who is determined to track this client's motion across the network
can do so by tracking its A record.

We should bear in mind that while MD5 isn't terribly secure, it's not
completely insecure either. In practice, the case where somebody's privacy
is going to be violated in this way is where someone is doing data mining,
and wants to be able to combine data mined about one host with data mined
about another host that happens to be the same host. It's going to be much
easier to do this with the hostname than to reverse-engineer the MD5 hash.
It's easier still to use the client identifier, if that's stored in the DNS,
so there is some limited value in doing *something* to increase the cost of
matching two identifiers, but the value of that really is quite limited.

So the problem I see here is that we want to do some obfuscation that is of
extremely limited value. And in order to "do it right," we need to add
extra steps to the DNS registration protocol to account for different
possible hash algorithms that might be used for obfuscation. So if the
choice is between doing it right and not doing it at all, I'm 100% behind not
doing it at all.

However, if the IESG is willing to accept a single algorithm, in hopes that it
will provide enough obfuscatory value that statistical analysis based on the
hostname portion of the client's FQDN is cheaper, I don't object to that.
It's only the additional complexification required to "do it right" to which
I object, because I don't think it adds any value.