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(_at_)ietf(_dot_)org
[mailto:dhcwg-bounces(_at_)ietf(_dot_)org]
On Behalf Of Pekka Savola
Sent: Saturday, November 26, 2005 2:10 PM
To: Ted Lemon
Cc: dhcwg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
iesg(_at_)ietf(_dot_)org;
namedroppers(_at_)ops(_dot_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf