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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 7 Feb 2006 17:41:04 -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. ]

Harald:

No, this would just mean that the client identity would be stored in raw
octet form instead of "encrypting" the data. It would have no impact on
anything else that I can see.

- Bernie

> -----Original Message-----
> From: Harald Tveit Alvestrand [mailto:[email-masked]] 
> Sent: Tuesday, February 07, 2006 5:36 PM
> To: Bernie Volz (volz); Ted Lemon; [email-masked]
> Cc: [email-masked]; Olaf Kolkman; Stig Venaas; 
> [email-masked]; Ralph Droms (rdroms)
> Subject: RE: [dhcwg] Open issues in DHCP FQDN, DHCID and 
> DDNS-DHCP Related RFCs
> 
> 
> 
> --On tirsdag, februar 07, 2006 17:28:54 -0500 "Bernie Volz (volz)" 
> <[email-masked]> wrote:
> 
> > Well, that certainly would be an easy solution (in terms of 
> changes to
> > the draft and also the conflict resolution draft). But, do 
> how practical
> > is this? How likely is the IESG to accept this?
> 
> (speaking as DHCP-head, not security-head)
> 
> would removing the hash entirely increase the probability of 
> confusion over 
> "who does what"?
> I thought it had a differentiation function too....
> 
>                         Harald
> 
> 

--
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: Ted Lemon <[email-masked]>
Date: Tue, 7 Feb 2006 16:06:52 -0700

> anything else that I can see.

Essentially, the concern is that you'd be publishing a stable token 
identifying a specific client in the DNS.   My counterargument to this 
concern is that the client's hostname is also a stable token identifying the 
client.

If you are concerned about privacy, you shouldn't be publishing _any_ tokens 
that identify the client in the DNS.   If you are not concerned about 
privacy, in the sense that for some reason you consider the value of putting 
your client's contact information into a public registry (the DNS) more 
important than keeping your client's identity private, then the fact that you 
are publishing two tokens in the DNS (the DUID and the hostname) that 
identify your client isn't a problem.