Documents: draft-ietf-dhc-ddns-resolution-10.txt
           draft-ietf-dnsext-dhcid-rr-10.txt
Reviewer: Harald Alvestrand
Review Date: Nov 28, 2005
Telechat Date:  Thursday 12/01/2005

Summary: Not ready. Technical issues.

The DDNS resolution document seems to be technically competent, and give a 
reasonable procedure for detecting conflicts in the case of multiple DDNS 
clients trying to update the same record.

The algorithm is, however, dependent on the content of the "disambiguating" 
record being computed in the same way by all participants - and the 
dnsext-dhcid document does not contain all information required to achieve 
this.

The problem is simple: The document gives three ways in which a DHCID RR 
can be created based on data from a client request. Section 3.4 does not 
specify which of the three to choose.

There are several ways to resolve this:

- Specify that the option furthest up the list for which information is 
available MUST be chosen, i.e use option 2 whenever a DUID is present
- Specify that all servers involved in a domain MUST be configured to pick 
the identifiers in the same way (the "local configuration" cop-out)
- Specify a procedure by which one can store/fetch data in the DNS about 
which algorithm is used to specify the DHCID

(The last two would also allow easy resolution of the "hash algorithm 
rollover" issue presented on the IETF list - but this may be unnecessary - 
see below)

(There is also no specification that would be "future proof" when new type 
codes are added to the registry from section 7 - this may be resolved 
either by specifying that new values require an update to this standard 
(and no registry is needed), by specifying a rule, or by specifying that 
new extensions must specify a rule. Future problem.)

The second problem with these drafts is the security claims of section 2. I 
don't believe that the issue is very serious - but the claim of being able 
to hide 40ish bits of information inside an 128-bit hash is harmful, 
because it's wrong.
In my opinion, there are only two choices:

- Abandon the idea that you can generate a DHCID and match it against a 
DHCID in the DNS without any external input
- Abandon the idea that you can hide information from a determined attacker 
using the hash

If the first option is taken, section 6.3.2 of ddns-resolution needs to 
specify that the DHCID is fetched - the DHCID can then (for instance) 
contain a large salt for the hash function; the DNS client can then see if 
it can successfully reconstruct the hash given the salt. (This also allows 
specifying the hash algorithm in the DHCID record's typecode).

If the second option is taken, all that is needed is a declaration that 
"the DUID of the client has very little value, so there isn't any sense in 
going to great lengths to protect it. Using a hash makes it a little 
difficult, and makes the records fixed size, which is good".

Nit: In section 3.1, an MD5 digest is described as having "n bytes". Unless 
you truncate it, I believe that "n" is always 16; leaving it as "n" looks 
untidy.