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

David:

I'm perfectly happy with MD5 too. I'm only doing this because this was apparently a blocking issue with the IESG. I'm not even an author on the DHCID RR draft, but have volunteered to sheppard it through because the authors have lost interest. (Though if one or more of the authors wants to pick this up, let me know and I'll send along the xml file for the draft.)

While we could do as Ted suggests (drop the encoding), I personally am uncomfortable with that because I think the information will leak out and better for it not to be obvious (though I guess if it was obvious it would teach folks quickly not to let it leak?). 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.

BTW, most of the options are definitely not fun for me because it will require more changes to the DHCID RR draft and the conflict resolution draft, since there needs to be something said about what happens if a DHCID RR exists and the data doesn't match -- if the "digest type" is different, then the updater might have to switch to that digest (if supported), ... If not supported, well, I guess one must assume the FQDN is in use and try a different FQDN.

- Bernie 

> -----Original Message-----
> From: David W. Hankins [mailto:[email-masked]] 
> Sent: Tuesday, February 07, 2006 7:31 PM
> To: Bernie Volz (volz)
> Cc: [email-masked]; dhcwg; Olaf Kolkman; 
> [email-masked]; Stig Venaas; Ólafur Gu>mundsson /DNSEXT 
> co-chair; Ralph Droms (rdroms)
> Subject: Re: [dhcwg] Open issues in DHCP FQDN, DHCID and 
> DDNS-DHCP Related RFCs
> 
> On Mon, Feb 06, 2006 at 09:59:11AM -0500, Bernie Volz (volz) wrote:
> > Possible solutions to the hash algorithm issue are:
> > 
> > 1. Switch from MD5 to SHA-1 or SHA-256 as the "base" 
> algorithm. This won't help down the road if these are found 
> to have significant weaknesses.
> > 
> > 2. Add a field (octet) to the DHCID RR RDATA to specify the 
> algorithm used (perhaps using the digest type field and 
> assignments used by the DS record, RFC 3658, and 
> http://www.iana.org/assignments/ds-rr-types). The RDATA would 
> thus be formatted as <RR TYPE (2 octets)><Digest Type (1 
> octet)><Digest (n octets)>. This also means a change to SHA-1 
> as the base algorithm or we'd need to request IANA to 
> allocate a MD5 digest code. (The SHA-1 digest is 20 octets 
> instead of MD5's 16 octets.)
> > 
> > 3. Incorporate the hash algorithm into the existing RR type 
> code field, which means a change of algorithm requires new RR 
> type codes to be assigned (likely 3 new codes per algorithm).
> > 
> > 4. Don't change the RDATA format or algorithm. Though this 
> would likely block this work from proceeding through the IESG?
> > 
> > Perhaps there's other solutions?
> > 
> > I'm inclined to pick 2 as I believe it meets all of the 
> IESG requirements and is the most flexible. Whether we switch 
> to SHA-1 or request a digest type assignment for MD5 is 
> debatable, but unless there are significantly different 
> export restrictions or licensing issues for MD5 vs. SHA-1, 
> let's just switch to SHA-1? 
> 
> 
> Funny, I was going to say '2 is right out'.  I don't like the
> implications of people trying to be reverse-algorithm compatible, or
> the fact that there's no way to roll between algorithms except
> all-stop, delete, restart.
> 
> 
> There's a contradiction in Ted's and Bernie's statements here 
> I want to
> point out.  Bernie says if SHA-X is found weak, that's a problem.  Ted
> says we can just remove the encoding.
> 
> One of these two statements has to be false if the other is true.  If
> we can remove the encoding, then we don't care if SHA-X is weak.  If
> we care if SHA-X is weak, then we can't remove the encoding.
> 
> Obviously I agree with Ted, I think the encoding is more political
> problem than technical reward.
> 
> In that case, there's no reason to care if SHA-x is weak because the
> alternative was cleartext.  So why not just go with door #1 if that
> makes the IESG happy?
> 
> One of my coworkers (who, wishing not to be named "bad idea 
> fairy" will
> for the moment be kept anonymous) suggests we adopt ROT13.  Actually,
> some zone admins might be able to read that without a filter, 
> so perhaps
> we should just XOR the field by 0xFF.
> 
> If cleartext is an acceptable answer, which I think it is, than any
> obfuscation that makes plaintext unreadable is equivalent, even if
> that equivalent obfuscation is a *different* weak digest algorithm.
> 
> 
> MD5 was the right answer.  There's no other way to say it.
> 
> 
> So in my final analysis, if switching to SHA-1 or SHA-256 gets it past
> IESG, I think that's better than ROT13 or XOR 0xFF, which I think is
> better than removing the encoding entirely, which I think is better
> than switching to an encoding byte, which I think is better 
> than making
> the encoding part of the type field.
> 
> But really, the success story here would be if we made no changes and
> just stuck with MD5.
> 
> -- 
> David W. Hankins		"If you don't do it right the 
> first time,
> Software Engineer			you'll just have to do 
> it again."
> Internet Systems Consortium, Inc.		-- Jack T. Hankins
>

---

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