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
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.
> -----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;
> Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:
> 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed
> 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
Ietf mailing list