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

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

> However, if the IESG is willing to accept a single algorithm, in hopes

that it=20
> will provide enough obfuscatory value that statistical analysis based

on the=20
> hostname portion of the client's FQDN is cheaper, I don't object to

that. =20
> It's only the additional complexification required to "do it right" to

which=20
> I object, because I don't think it adds any value.


- Bernie

> -----Original Message-----
> From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20
> Sent: Tuesday, February 07, 2006 8:50 PM
> To: dhcwg@ietf.org
> Cc: Bernie Volz (volz); David W. Hankins; Olaf Kolkman;=20
> namedroppers@ops.ietf.org; Harald@alvestrand.no; Stig Venaas;=20
> ogud@ogud.com; Ralph Droms (rdroms)
> Subject: Re: [dhcwg] Open issues in DHCP FQDN, DHCID and=20
> DDNS-DHCP Related RFCs
>=20
> On Tuesday 07 February 2006 18:04, Bernie Volz (volz) wrote:
> > I also don't recall the history (because I either wasn't=20

> involved or was
> > fairly disinterested at the time) the reason for encoding=20

> this, but suspect
> > it was to make it somewhat difficult for someone to find=20

> the client's
> > identity and potentially track the user through the Internet as they
> > connect to different access networks (assuming the DHCID RR=20

> was available).
> > I don't believe the goal was ever to make it impossible,=20

> just somewhat
> > difficult so that most folks wouldn't bother.

>=20
> The original motivation for using MD5 was to protect the=20
> privacy of the client=20
> by not publishing its client identifier (typically the MAC=20
> address of the=20
> ethernet card) in the DNS. But we're already publishing the=20
> client's=20
> identity in the DNS in the form of the hostname it sends to=20
> the server.
>=20
> So someone who is determined to track this client's motion=20
> across the network=20
> can do so by tracking its A record.
>=20
> We should bear in mind that while MD5 isn't terribly secure, it's not=20
> completely insecure either. In practice, the case where=20
> somebody's privacy=20
> is going to be violated in this way is where someone is doing=20
> data mining,=20
> and wants to be able to combine data mined about one host=20
> with data mined=20
> about another host that happens to be the same host. It's=20
> going to be much=20
> easier to do this with the hostname than to reverse-engineer=20
> the MD5 hash. =20
> It's easier still to use the client identifier, if that's=20
> stored in the DNS,=20
> so there is some limited value in doing *something* to=20
> increase the cost of=20
> matching two identifiers, but the value of that really is=20
> quite limited.
>=20
> So the problem I see here is that we want to do some=20
> obfuscation that is of=20
> extremely limited value. And in order to "do it right," we=20
> need to add=20
> extra steps to the DNS registration protocol to account for different=20
> possible hash algorithms that might be used for obfuscation. =20
> So if the=20
> choice is between doing it right and not doing it at all, I'm=20
> 100% behind not=20
> doing it at all.
>=20
> However, if the IESG is willing to accept a single algorithm,=20
> in hopes that it=20
> will provide enough obfuscatory value that statistical=20
> analysis based on the=20
> hostname portion of the client's FQDN is cheaper, I don't=20
> object to that. =20
> It's only the additional complexification required to "do it=20
> right" to which=20
> I object, because I don't think it adds any value.
>=20



--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: