RE: Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs

[Ólafur Guðmundsson /DNSEXT co-chair <[e-mail]>]

At 22:57 22/02/2006, Bernie Volz \(volz\) wrote:

>Hi:
>
>I have just submitted revised versions of the 
>drafts. Copies of what I submitted are available at:
>
>Ralph had sent a list of 11 issues to the 
>mailing list. And, then followed up with 19 more 
>raised by Pekka Savola but that list of issues 
>did not go to the DHC WG. Both emails are below 
>so you can see the full list of 30 issues.
>
>I believe I have addressed all of them.

<DNSEXT chair-hat=on>
Bernie,  thank you for your diligent work on getting the document
set updated.


>Some key changes are that the DHCID RR now has 
>an additional field to specify the digest type 
>and we've switched to using SHA-256 instead of MD5.

<DNSEXT chair-hat=off>
To give a little background on this change.
During the document revision there was a off-list discussion that involved
Ralph Droms, Olafur Gudmundsson, David Harkins, Sam Hartman, Ted Lemon
and Bernie Volz. This recollection is mine apologies to anyone that I
misrepresent/misunderstood/omitted.

This results of discussion need to be documented, and I'm doing that here.
   1. Without obfuscation of the client ID, it is trivial to track clients
         as the move around.
   1.5 No protocol change can protect a client that exposes its Client ID
       over a public network, such as the IETF wireless net. But obfuscation
       still provides large number of clients with increased privacy.

   2. In the overall schema of things he cost difference between using MD5,
      SHA1 and SHA256 is not that great, thus the 
strongest one should be used.

   3. Changing obfuscation functions over time can either
      be accomplished by using a new field in DHCID or new RR type.
      It is better not having to do a type code rollover. The rollover
      to a new digest function MUST be defined by the NEW definition,
      by this document. The reason for this is we are not sure if there
      is ever a need so spending time on that right now is not productive,
      and by selecting the one of the strongest functions available
      right now we hope to push this far into the future, i.e. after
      Ted, Ralph and I retire from the ietf :-).


>We need to figure out what the next step is -- 
>do we need another DHC / DNSEXT WG last-call or 
>do we send these to the IESG directly?



<DNSEXT chair-hat=on>
Most of the changes are "minor" and I do not see need for a last call,
either at the WG level or IETF.
Scanning the documents I'm concerned that the examples are TBD, thus
I request that at least 3 parties calculate the new digests and post
their results. After which the DHCID document is needs to be updated.

>If there is strong demand, I can develop diff 
>files but as there were a lot of minor edits and 
>changes to references, it likely will be rather large set of differences.

Diffs and (partial history are available at
http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-dhcid-rr/

http://tools.ietf.org/wg/dhc/draft-ietf-dhc-ddns-resolution/

http://tools.ietf.org/wg/dhc/draft-ietf-dhc-fqdn-option/

http://tools.ietf.org/wg/dhc/draft-ietf-dhc-dhcpv6-fqdn/

         Ólafur