This would, as Ted indicates, greatly complicate the entire update sequence. The current update sequence (see draft-ietf-dhc-ddns-resolution-10.txt), never does a query of the RRs in the server. Therefore, either we'd have to do a query first to obtain the DHCID RR and extract the algorithm so we can do the comparison, or we'd have to try each of the algorithms in a DNS update operation. Neither of these is particularily pleasant (especially considering that things can change between DNS operations). And, if not all implementations support all algorithms, you'd have real interop problems. And, what's the benefit? It isn't like this information is hyper sensitive (come on, IPv6 uses the mac address in the link identifier -- yes, I know about RFC 3041). While MD5 could be compromised, you can't necessarily get back the mac address that was used to generate the value. Yet, we also have to remember that we're dealing with a 48-bit *INPUT* in many cases for the DHCID -- the mac address. A brute force attack is not out of the question if you really wanted to get the data (and given the well known 24-bit OID values, you could probably cut down the bruce force attack to make it very reasonable whatever scheme we used). If a client identifier or DUID is used, this does likely mean more bits but most client identifiers and DUIDs are based on mac addresses. So, let's be realistic here and not unnecessarily complicate matters for no real benefit. If there is a strong argument to improve the security of this information, we can debate whether SHA1 or SHA-256 be used for the start. But, I for one don't see the need. - Bernie > -----Original Message----- > From: dhcwg-bounces@xxxxxxxx [mailto:dhcwg-bounces@xxxxxxxx] > On Behalf Of Pekka Savola > Sent: Saturday, November 26, 2005 2:10 PM > To: Ted Lemon > Cc: dhcwg@xxxxxxxx; ietf@xxxxxxxx; iesg@xxxxxxxx; > namedroppers@xxxxxxxxxxxx > Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: > 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed > Standard] > > On Sat, 26 Nov 2005, Ted Lemon wrote: > > 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. > > AFAICS, it shouldn't be all that complicated as long as the > implementations [checking for conflicts] support all the algorithms > used at the site, right? > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > _______________________________________________ > dhcwg mailing list > dhcwg@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf