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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 28 Nov 2005 17:00:39 -0500

> 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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Steven M. Bellovin
> Sent: Monday, November 28, 2005 11:49 AM
> To: Ted Lemon
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> Pekka Savola; [email-masked]
> Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 
> 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed 
> Standard] 
> 
> In message <[email-masked]>, Ted Lemon writes:
> >Making a hash function interchangeable in DHCID makes the 
> conflict detection 
> >algorithm hugely more complicated, and possibly not workable 
> at all.   Think 
> >about how that would work.
> >
> 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.  The 
> updater would then use local policy -- that is, an ordered list of 
> preferred hash functions -- until it found one that was in the 
> response.  That one would be used.  If no locally-known hash 
> functions 
> are in the list, it should behave as if there were no DHCID records 
> present for that name.  DNSSEC could protect against 
> downgrade attacks.
> (Speaking of which -- were I still AD, I'd ding this document for an
> inadequate Security Considerations section -- apart from the 
> lack of discussion of brute force attacks, you should cite 
> 3833 for DNS 
> attacks and explain what the risks are if someone can crack the hash 
> function by any means, including brute force or eavesdropping on the 
> wire or (perhaps) a misbehaving updater.)
> 
> If you don't agree, I'd strongly suggest using SHA-256 
> instead of MD5.  
> Yes, it's more expensive, but I doubt that that's a major hit on 
> overall system performance here.  It would also be useful to 
> include in 
> the document some discussion of upgrade strategy -- how would we ever 
> switch to a new hash function?  That's non-trivial even for protocols 
> designed for agility, as Eric Rescorla and I have shown.  No 
> matter how 
> it's done, this one is among the very hardest, since DNS 
> servers would 
> have to supply DHCID records for several hashes for a number of years.
> 
> 		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
> 
> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 28 Nov 2005 23:13:55 +0100

> 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