Subject: Re: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Feb 2006 18:49:36 -0700

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.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 08 Feb 2006 08:45:39 +0100

--On 7. februar 2006 20:04 -0500 "Bernie Volz (volz)" <[email-masked]> 
wrote:

> David:
>
> I'm perfectly happy with MD5 too. I'm only doing this because this was
> apparently a blocking issue with the IESG.

My reading (which is about as reliable as tea leaves) is that keeping MD5, 
and changing the document to say that it doesn't purport to protect 
identities, is also a valid way forward.

It's the inconsistency between the claim that MD5 helps security and the 
known weakness of MD5 that's got the security ADs up in arms.

                       Harald

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg