Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Nov 2005 16:32:40 -0700

The Nominum DHCP server (DCS) supports the exact mechanism described in the 
collection of documents, except that the data is stored in a TXT record 
rather than a DHCID record, because we are waiting on the DHCID record.   We 
also implement the older version of the protocol that the ISC server 
supports, which as David says is only slightly different than the current 
spec.

--
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: Tue, 29 Nov 2005 07:40:08 +0100

Thanks - these responses point out very clearly that the mechanism is being 
used as described, *except* for the bit that's contentious (use of MD5 for 
information hiding).

This means that we will not have a backwards compatibility issue with the 
installed base if we change the format of the record, but *will* have a 
procedural compatibility issue if we don't keep the property of "you can 
know the expected content of the record without fetching it".

                   Harald

--On mandag, november 28, 2005 17:20:09 -0500 "Bernie Volz (volz)" 
<[email-masked]> wrote:

> Harald:
>
> Yes, I can.
>
> The ISC's DHCP server (www.isc.org) does this (I'm not sure whether it
> uses MD5 to encode the client identity or not). Ted might know for sure.
>
> As does Cisco's Network Registrar (though it presently doesn't encode
> the data using MD5).
>
> And, I'm pretty sure several other DHCP vendors do this -- though
> whether they're using MD5 or not I can't be sure.
>
> These servers are in production all over and have been doing this for
> many years.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 29 Nov 2005 00:03:03 -0700

> know the expected content of the record without fetching it".

Yup.   My only objection to changing the hash algorithm is that it means a rev 
of the document that could cause us to go through another wglc or ietf last 
call (as opposed to editorial changes, which presumably would not).   
Otherwise, while I don't think it makes any difference, it's otherwise fine 
to use SHA-256 instead of MD5.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 29 Nov 2005 08:26:51 +0100

--On tirsdag, november 29, 2005 00:03:03 -0700 Ted Lemon 
<[email-masked]> wrote:

> Yup.   My only objection to changing the hash algorithm is that it means
> a rev  of the document that could cause us to go through another wglc or
> ietf last  call (as opposed to editorial changes, which presumably would
> not).    Otherwise, while I don't think it makes any difference, it's
> otherwise fine  to use SHA-256 instead of MD5.

After reading the docs, I don't think it makes any difference either.

                       Harald

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 28 Nov 2005 23:18:28 +0000

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

> uses MD5 to encode the client identity or not). Ted might know for sure.

It does, though it only encodes the client identity (client identifier
option or chaddr), it does not include the FQDN like the current DHCID
draft does.

There are a few niggling bits that are different, and obviously
incompatible (not just because it's encoded as hexadecimal in a TXT
record), but on all points that are topical to this discussion it's
the same.

-- 
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: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 28 Nov 2005 17:20:09 -0500

Harald:

Yes, I can.

- Bernie

> -----Original Message-----
> From: Harald Tveit Alvestrand [mailto:[email-masked]] 
> Sent: Monday, November 28, 2005 5:14 PM
> To: Bernie Volz (volz); Steven M. Bellovin; Ted Lemon
> Cc: [email-masked]; Pekka Savola; [email-masked]; 
> [email-masked]
> Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last 
> Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to 
> Proposed Standard] 
> 
> 
> 
> --On mandag, november 28, 2005 17:00:39 -0500 "Bernie Volz (volz)" 
> <[email-masked]> wrote:
> 
> >> I confess that I don't see the problem.  The updater would do a DNS
> >> query for DHCID RRs; it would be given all of the stored
> >> records.
> >
> > That's not how the current update algorithm works. Sure, we could do
> > almost anything but we'll be debating this for the next 100 
> years. It
> > has already gone on for almost 10 years!!!
> >
> > Can we get serious about this and really ask what are we trying to
> > protect.
> >
> > And where were you folks when IPv6 was designed to use the 
> mac address
> > as the interface identifier. Come on.
> >
> > We're trying to make it NON-TRIVIAL, not impossible.
> >
> > This technique has been in use for years by implementations 
> using TXT
> > records because we've been unable to get the DHCID RR approved.
> 
> Bernie,
> 
> just checking....
> this puzzle seems to have several distinct pieces:
> 
> - the DHCP options to talk about DNS names. Nobody seems to 
> have any large 
> problem with that.
> - the mechanism for detecting conflicts. Nobody seems to have 
> any large 
> problem with that.
> - the exact mechanism by which one stores a value identifying 
> the client in 
> the DNS without giving out useful information about the 
> client. That's 
> where all the shouting is.
> 
> Can you verify for me that all three parts are being done today in 
> production, in just the way (apart from RR type) specified in 
> the I-Ds?
> 
>                         Harald
>