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

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Feb 2006 23:10:29 -0500

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

I think the main think I at least am asking for is multiple
algorithms.  Russ is asking for some analysis based on comments from
Steve Bellovin.

I think we may need to spend some time on this--either in Dallas or a
conference call to make any progress.

I think the primary issue in my mind is whether this mechanism works
at all.  Once you figure out a client identifier you can test whether
a particular lease is a particular client.  So, while I may not be
able to easily track everyone, this supports targeted tracking fairly
easily.

I don't see a way around that without having shared secrets known by
the DHCP servers.  I'm not saying that we should mandate that or
perhaps even that we should support it.

But I'm becoming even more convinced that Steve Bellovin is right and
that we need to understand what problem we're solving here.

I do still feel strongly about the multiple algorithms issue.  However
I don't think I'm going to be in a position to understand and
appreciate arguments on that issue until we have a discussion about
what we're trying to accomplish and about what the mechanisms are.

The one argument I explicitly do not accept is the deployed base
argument.  This is a new option that is first before the IETF and has
first received cross-area review now.  RR types have not even been
assigned.  I'm sorry the process has taken a long time.  The right fix
for that is to work on process efficiency; I think we are all trying
to do that.  I know the DHCP working group has improved a lot recently
and I believe the IESG has as well.

--Sam

--
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: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 7 Feb 2006 20:53:52 -0500

Well, let's ask the IESG (added to TO:) ...

> 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.

- Bernie

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]] 
> Sent: Tuesday, February 07, 2006 8:50 PM
> To: [email-masked]
> Cc: Bernie Volz (volz); David W. Hankins; Olaf Kolkman; 
> [email-masked]; [email-masked]; Stig Venaas; 
> [email-masked]; Ralph Droms (rdroms)
> Subject: Re: [dhcwg] Open issues in DHCP FQDN, DHCID and 
> DDNS-DHCP Related RFCs
> 
> 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.
>