Subject: RE: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 22 Feb 2006 22:57:49 -0500

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Hi:

I have just submitted revised versions of the drafts. Copies of what I submitted are available at:

ftp://ftpeng.cisco.com/volz/draft-ietf-dhc-ddns-resolution-11.txt
ftp://ftpeng.cisco.com/volz/draft-ietf-dhc-fqdn-option-12.txt
ftp://ftpeng.cisco.com/volz/draft-ietf-dhc-dhcpv6-fqdn-04.txt
ftp://ftpeng.cisco.com/volz/draft-ietf-dnsext-dhcid-rr-11.txt

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.

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.

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?

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.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ralph Droms (rdroms)
> Sent: Thursday, February 02, 2006 4:38 PM
> To: [email-masked]; dhcwg
> Cc: Olaf Kolkman; [email-masked]; Stig Venaas; Ólafur 
> Gu>mundsson /DNSEXT co-chair
> Subject: [dhcwg] Open issues in DHCP FQDN, DHCID and 
> DDNS-DHCP Related RFCs
> 
> Included below is a summary list of the open issues in this package of
> documents:
> 
> draft-ietf-dnsext-dhcid-rr-10.txt
> draft-ietf-dhc-ddns-resolution-10.txt
> draft-ietf-dhc-dhcpv6-fqdn-03.txt
> draft-ietf-dhc-fqdn-option-11.txt
> 
> 1.  Which DHCID RR encoding does an IPv4 client/server use (Brian
>     Carpenter; Bernie has submitted text to resolve the issue)
> 2.  Editorial comment on resolution doc section 6.3.2 and AAAA records
>     (Ted Hardie)
> 3.  s/byte/octet/g  (Scott Hollenbeck)
> 4.  Use example. or example.com. in examples (Scott Hollenbeck)
> 5.  s/signature/hash value/g (Russ Housley)
> 6.  In the resolution doc "security considerations" s/where or/whether
>     or/ (Jon Peterson)
> 7.  Add an 8-bit algorithm identifier to the DHCID RR to
>     support algorithm agility (Allison Mankin)
> 8.  Use of MD5 as opposed to a stronger hash function (Sam Hartman,
>     Russ Housley)
> 9.  Hash agility (Sam Hartman, Allison Mankin)
> 10. Russ's comment that an attacker that has some knowledge of MAC
>     addresses does not need to do lot of work. I think this can be
>     addressed in security considerations by saying this is not privacy
>     but just obfuscation (Russ Housley)
> 11. UTF-8 character set usage (Harald Alvestrand, gen-art)
> 
> Issues 1-6 are strictly editorial and the document editors 
> will revise the
> documents to resolve those issues in the next revision.
> 
> Issues 7-10 are all related to the hash algorithm specified 
> in the documents
> and the requirements for algorithm agility.  We will resolve 
> those issues
> through an e-mail discussion to follow.
> 
> Issue 11 needs some clarification; Harald, I hope you'll kick 
> off a separate
> thread to discuss how to resolve this issue.
> 
> - Ralph, for Olafur, Stig and Olaf

> -----Original Message-----
> From: Ralph Droms (rdroms) 
> Sent: Wednesday, February 08, 2006 2:28 PM
> To: Bernie Volz (volz)
> Cc: Stig Venaas; Olaf Kolkman; Ólafur Gu>mundsson /DNSEXT 
> co-chair; [email-masked]
> Subject: Re: Open issues in DHCP FQDN, DHCID and DDNS-DHCP 
> Related RFCs
> 
> Bernie - it appears there are several issues from Pekka that are not
> included in the IESG Discusses (summary below)...
> 
> On 2/8/06 7:57 AM, "Pekka Savola" <[email-masked]> wrote:
> 
> > On Thu, 2 Feb 2006, Ralph Droms wrote:
> >> Included below is a summary list of the open issues in this package
> >> of documents:
> >> 
> >> draft-ietf-dnsext-dhcid-rr-10.txt
> >> draft-ietf-dhc-ddns-resolution-10.txt
> >> draft-ietf-dhc-dhcpv6-fqdn-03.txt
> >> draft-ietf-dhc-fqdn-option-11.txt
> > 
> > Just checking, did you also check the following mails:
> > 
> > http://www1.ietf.org/mail-archive/web/ietf/current/msg38995.html
> > http://www1.ietf.org/mail-archive/web/ietf/current/msg38994.html
> > http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05678.html
> 
> Summarizing these issues (starting from 12 after previous 
> issues 1-11):
> 
> (Substantive)
> 12. Interaction between DHCP/DHCID and non-DHCP clients
> 13. Server always decides policy on updating existing RRs (section
>     6.3.2 of ddns-resolution)
> 14. Section 5 of ddns-resolution on DDNS RR TTLs is not 
> germane to conflict
>     resolution
> 15. Replace "DHCP client" with "node" in section 3 of ddns-resolution
> 16. Does section 6.1 of the DHCPv6 FQDN spec work with Rapid Commit?
> 17. In section 6 of the DHCPv6 FQDN spec (third bullet in 
> list), how does
>     the server know if it has the credentials before it tries 
> the update?
> 18. Security considerations section of DHCPv6 FQDN spec 
> should include a
>     pointer to the security considerations section of ddns-resolution
> 19. Reword process to define new DHCID RR type codes to use RFC 2434
>     process w/o modification
> 
> (Editorial)
> 20. Use "example.com" in example FQDNs
> 21. In the Intro of ddns-resolution, client and server 
> negotiate update of
>     PTR RR as well as A and AAAA RRs
> 22. In section 4 of ddns-resolution, "DHCPREQUST" is 
> DHCPv4-specific; add
>     ref to corresponding DHCPv6 message
> 23. First sentence of section 6.5, ddns-resolution: s/is be/is to be/
> 24. Change refs to RFC 2131 and RFC 3315 to Normative in 
> ddns-resolution
> 25. In DHCPv6 FQDN spec, s/prescence/presence/
> 26. In the Abstract and Intro of the DHCID RR spec, non-DHCP 
> nodes can be
>     involved in conflicts as well as DHCP clients
> 27. DHCID RR spec shold also include an example of DHCPv6 DHCID RR
>     generation
> 28. Use RFC 3330 documentation prefix instead of 10.0.0.1 (10/8)
> 29. Remove citations from abstracts
> 30. Refer to both DHCPv4 and DHCPv6 in the Intro of the DHCID RR spec
> 
> Seems like we ought to take a look at these issues and 
> resolve them as well
> as the IESG Discuss issues.
> 
> - RALPH

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Sat, 25 Feb 2006 13:20:20 -0500

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.
>

<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