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

From: Ralph Droms <[email-masked]>
Date: Thu, 02 Feb 2006 16:38:27 -0500

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

--
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: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 6 Feb 2006 09:59:11 -0500

As I'd like to re-submit these drafts as soon as possible, we need to resolve

>    but just obfuscation (Russ Housley)

Possible solutions to the hash algorithm issue are:

1. Switch from MD5 to SHA-1 or SHA-256 as the "base" algorithm. This won't help down the road if these are found to have significant weaknesses.

2. Add a field (octet) to the DHCID RR RDATA to specify the algorithm used (perhaps using the digest type field and assignments used by the DS record, RFC 3658, and http://www.iana.org/assignments/ds-rr-types). The RDATA would thus be formatted as <RR TYPE (2 octets)><Digest Type (1 octet)><Digest (n octets)>. This also means a change to SHA-1 as the base algorithm or we'd need to request IANA to allocate a MD5 digest code. (The SHA-1 digest is 20 octets instead of MD5's 16 octets.)

3. Incorporate the hash algorithm into the existing RR type code field, which means a change of algorithm requires new RR type codes to be assigned (likely 3 new codes per algorithm).

4. Don't change the RDATA format or algorithm. Though this would likely block this work from proceeding through the IESG?

Perhaps there's other solutions?

I'm inclined to pick 2 as I believe it meets all of the IESG requirements and is the most flexible. Whether we switch to SHA-1 or request a digest type assignment for MD5 is debatable, but unless there are significantly different export restrictions or licensing issues for MD5 vs. SHA-1, let's just switch to SHA-1? 

Comments please!

- Bernie

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 7 Feb 2006 17:28:54 -0500

Well, that certainly would be an easy solution (in terms of changes to
the draft and also the conflict resolution draft). But, do how practical
is this? How likely is the IESG to accept this?

- Bernie 

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]] 
> Sent: Monday, February 06, 2006 9:48 PM
> To: [email-masked]
> Cc: Bernie Volz (volz); [email-masked]; Olaf 
> Kolkman; [email-masked]; Stig Venaas; [email-masked]; 
> Ralph Droms (rdroms)
> Subject: Re: [dhcwg] Open issues in DHCP FQDN, DHCID and 
> DDNS-DHCP Related RFCs
> 
> On Monday 06 February 2006 07:59, Bernie Volz (volz) wrote:
> My vote would be to take out the hash entirely - it was 
> unnecessary to begin 
> with, and the idea of radically complexifying the protocol to 
> make it more 
> secure when there was no real need for it in the first place 
> strikes me as a 
> huge and painful mistake.
>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 07 Feb 2006 23:35:37 +0100

> is this? How likely is the IESG to accept this?

(speaking as DHCP-head, not security-head)

would removing the hash entirely increase the probability of confusion over 
"who does what"?
I thought it had a differentiation function too....

                        Harald

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 7 Feb 2006 17:41:04 -0500

Harald:

No, this would just mean that the client identity would be stored in raw
octet form instead of "encrypting" the data. It would have no impact on
anything else that I can see.

- Bernie

> From: Harald Tveit Alvestrand [mailto:[email-masked]] 
> Sent: Tuesday, February 07, 2006 5:36 PM
> To: Bernie Volz (volz); Ted Lemon; [email-masked]
> Cc: [email-masked]; Olaf Kolkman; Stig Venaas; 
> [email-masked]; Ralph Droms (rdroms)
> Subject: RE: [dhcwg] Open issues in DHCP FQDN, DHCID and 
> DDNS-DHCP Related RFCs
> 
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Feb 2006 16:06:52 -0700

> anything else that I can see.

Essentially, the concern is that you'd be publishing a stable token 
identifying a specific client in the DNS.   My counterargument to this 
concern is that the client's hostname is also a stable token identifying the 
client.

If you are concerned about privacy, you shouldn't be publishing _any_ tokens 
that identify the client in the DNS.   If you are not concerned about 
privacy, in the sense that for some reason you consider the value of putting 
your client's contact information into a public registry (the DNS) more 
important than keeping your client's identity private, then the fact that you 
are publishing two tokens in the DNS (the DUID and the hostname) that 
identify your client isn't a problem.

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 7 Feb 2006 20:04:02 -0500

David:

I'm perfectly happy with MD5 too. I'm only doing this because this was apparently a blocking issue with the IESG. I'm not even an author on the DHCID RR draft, but have volunteered to sheppard it through because the authors have lost interest. (Though if one or more of the authors wants to pick this up, let me know and I'll send along the xml file for the draft.)

While we could do as Ted suggests (drop the encoding), I personally am uncomfortable with that because I think the information will leak out and better for it not to be obvious (though I guess if it was obvious it would teach folks quickly not to let it leak?). I also don't recall the history (because I either wasn't involved or was fairly disinterested at the time) the reason for encoding this, but suspect it was to make it somewhat difficult for someone to find the client's identity and potentially track the user through the Internet as they connect to different access networks (assuming the DHCID RR was available). I don't believe the goal was ever to make it impossible, just somewhat difficult so that most folks wouldn't bother.

BTW, most of the options are definitely not fun for me because it will require more changes to the DHCID RR draft and the conflict resolution draft, since there needs to be something said about what happens if a DHCID RR exists and the data doesn't match -- if the "digest type" is different, then the updater might have to switch to that digest (if supported), ... If not supported, well, I guess one must assume the FQDN is in use and try a different FQDN.

- Bernie 

> From: David W. Hankins [mailto:[email-masked]] 
> Sent: Tuesday, February 07, 2006 7:31 PM
> To: Bernie Volz (volz)
> Cc: [email-masked]; dhcwg; Olaf Kolkman; 
> [email-masked]; Stig Venaas; Ólafur Gu>mundsson /DNSEXT 
> co-chair; Ralph Droms (rdroms)
> On Mon, Feb 06, 2006 at 09:59:11AM -0500, Bernie Volz (volz) wrote:
> > 1. Switch from MD5 to SHA-1 or SHA-256 as the "base" 
> algorithm. This won't help down the road if these are found 
> to have significant weaknesses.
> > 
> > 2. Add a field (octet) to the DHCID RR RDATA to specify the 
> algorithm used (perhaps using the digest type field and 
> assignments used by the DS record, RFC 3658, and 
> http://www.iana.org/assignments/ds-rr-types). The RDATA would 
> thus be formatted as <RR TYPE (2 octets)><Digest Type (1 
> octet)><Digest (n octets)>. This also means a change to SHA-1 
> as the base algorithm or we'd need to request IANA to 
> allocate a MD5 digest code. (The SHA-1 digest is 20 octets 
> instead of MD5's 16 octets.)
> > 
> > 3. Incorporate the hash algorithm into the existing RR type 
> code field, which means a change of algorithm requires new RR 
> type codes to be assigned (likely 3 new codes per algorithm).
> > 
> > 4. Don't change the RDATA format or algorithm. Though this 
> would likely block this work from proceeding through the IESG?
> > 
> > I'm inclined to pick 2 as I believe it meets all of the 
> IESG requirements and is the most flexible. Whether we switch 
> to SHA-1 or request a digest type assignment for MD5 is 
> debatable, but unless there are significantly different 
> export restrictions or licensing issues for MD5 vs. SHA-1, 
> let's just switch to SHA-1? 
> 
> 
> Funny, I was going to say '2 is right out'.  I don't like the
> implications of people trying to be reverse-algorithm compatible, or
> the fact that there's no way to roll between algorithms except
> all-stop, delete, restart.
> 
> 
> There's a contradiction in Ted's and Bernie's statements here 
> I want to
> point out.  Bernie says if SHA-X is found weak, that's a problem.  Ted
> says we can just remove the encoding.
> 
> One of these two statements has to be false if the other is true.  If
> we can remove the encoding, then we don't care if SHA-X is weak.  If
> we care if SHA-X is weak, then we can't remove the encoding.
> 
> Obviously I agree with Ted, I think the encoding is more political
> problem than technical reward.
> 
> In that case, there's no reason to care if SHA-x is weak because the
> alternative was cleartext.  So why not just go with door #1 if that
> makes the IESG happy?
> 
> One of my coworkers (who, wishing not to be named "bad idea 
> fairy" will
> for the moment be kept anonymous) suggests we adopt ROT13.  Actually,
> some zone admins might be able to read that without a filter, 
> so perhaps
> we should just XOR the field by 0xFF.
> 
> If cleartext is an acceptable answer, which I think it is, than any
> obfuscation that makes plaintext unreadable is equivalent, even if
> that equivalent obfuscation is a *different* weak digest algorithm.
> 
> 
> MD5 was the right answer.  There's no other way to say it.
> 
> 
> So in my final analysis, if switching to SHA-1 or SHA-256 gets it past
> IESG, I think that's better than ROT13 or XOR 0xFF, which I think is
> better than removing the encoding entirely, which I think is better
> than switching to an encoding byte, which I think is better 
> than making
> the encoding part of the type field.
> 
> But really, the success story here would be if we made no changes and
> just stuck with MD5.
> 
> -- 
> David W. Hankins		"If you don't do it right the 
> first time,
> Software Engineer			you'll just have to do 
> it again."
> Internet Systems Consortium, Inc.		-- Jack T. Hankins
>

---

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Feb 2006 23:10:29 -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. ]

I think the main think I at least am asking for is multiple
algorithms.  Russ is asking for some analysis based on comments from
Steve Bellovin.

I think we may need to spend some time on this--either in Dallas or a
conference call to make any progress.

I think the primary issue in my mind is whether this mechanism works
at all.  Once you figure out a client identifier you can test whether
a particular lease is a particular client.  So, while I may not be
able to easily track everyone, this supports targeted tracking fairly
easily.

I don't see a way around that without having shared secrets known by
the DHCP servers.  I'm not saying that we should mandate that or
perhaps even that we should support it.

But I'm becoming even more convinced that Steve Bellovin is right and
that we need to understand what problem we're solving here.

I do still feel strongly about the multiple algorithms issue.  However
I don't think I'm going to be in a position to understand and
appreciate arguments on that issue until we have a discussion about
what we're trying to accomplish and about what the mechanisms are.

The one argument I explicitly do not accept is the deployed base
argument.  This is a new option that is first before the IETF and has
first received cross-area review now.  RR types have not even been
assigned.  I'm sorry the process has taken a long time.  The right fix
for that is to work on process efficiency; I think we are all trying
to do that.  I know the DHCP working group has improved a lot recently
and I believe the IESG has as well.

--Sam

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 7 Feb 2006 20:53:52 -0500

Well, let's ask the IESG (added to TO:) ...

> However, if the IESG is willing to accept a single algorithm, in hopes
that it 
> will provide enough obfuscatory value that statistical analysis based
on the 
> hostname portion of the client's FQDN is cheaper, I don't object to
that.   
> It's only the additional complexification required to "do it right" to
which 
> I object, because I don't think it adds any value.

- Bernie

> From: Ted Lemon [mailto:[email-masked]] 
> Sent: Tuesday, February 07, 2006 8:50 PM
> To: [email-masked]
> Cc: Bernie Volz (volz); David W. Hankins; Olaf Kolkman; 
> [email-masked]; [email-masked]; Stig Venaas; 
> On Tuesday 07 February 2006 18:04, Bernie Volz (volz) wrote:
> > I also don't recall the history (because I either wasn't 
> involved or was
> > fairly disinterested at the time) the reason for encoding 
> this, but suspect
> > it was to make it somewhat difficult for someone to find 
> the client's
> > identity and potentially track the user through the Internet as they
> > connect to different access networks (assuming the DHCID RR 
> was available).
> > I don't believe the goal was ever to make it impossible, 
> just somewhat
> > difficult so that most folks wouldn't bother.
> 
> The original motivation for using MD5 was to protect the 
> privacy of the client 
> by not publishing its client identifier (typically the MAC 
> address of the 
> ethernet card) in the DNS.   But we're already publishing the 
> client's 
> identity in the DNS in the form of the hostname it sends to 
> the server.
> 
> So someone who is determined to track this client's motion 
> across the network 
> can do so by tracking its A record.
> 
> We should bear in mind that while MD5 isn't terribly secure, it's not 
> completely insecure either.   In practice, the case where 
> somebody's privacy 
> is going to be violated in this way is where someone is doing 
> data mining, 
> and wants to be able to combine data mined about one host 
> with data mined 
> about another host that happens to be the same host.   It's 
> going to be much 
> easier to do this with the hostname than to reverse-engineer 
> the MD5 hash.    
> It's easier still to use the client identifier, if that's 
> stored in the DNS, 
> so there is some limited value in doing *something* to 
> increase the cost of 
> matching two identifiers, but the value of that really is 
> quite limited.
> 
> So the problem I see here is that we want to do some 
> obfuscation that is of 
> extremely limited value.   And in order to "do it right," we 
> need to add 
> extra steps to the DNS registration protocol to account for different 
> possible hash algorithms that might be used for obfuscation.  
>  So if the 
> choice is between doing it right and not doing it at all, I'm 
> 100% behind not 
> doing it at all.
> 
> However, if the IESG is willing to accept a single algorithm, 
> in hopes that it 
> will provide enough obfuscatory value that statistical 
> analysis based on the 
> hostname portion of the client's FQDN is cheaper, I don't 
> object to that.   
> It's only the additional complexification required to "do it 
> right" to which 
> I object, because I don't think it adds any value.
>

---

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

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

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

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

---

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

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sat, 25 Feb 2006 13:49:28 -0500

> their results. After which the DHCID document is needs to be updated.

I figured I'd wait until we settled on whether this was the correct way to go before supplying the DHCID RR data for the 3 examples. (I also didn't have a SHA-256 implementation readily at hand to actually write a quick program but implementations are readily available, such as in the OpenSSL distribution. I wanted to get the updated draft out figuring that the examples can be handled during the RFC editing process.)

- Bernie

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sat, 25 Feb 2006 16:37:24 -0500

Here's my calculation of the 3 examples in the DHCID RR draft.

Example 1:
     client.example.com.   A       10.0.0.1
     client.example.com.   DHCID   AAABxLmlskllE0MVjd57zHcWmEH3pCQ6VytcKD//7es/deY=

Example 2:
     chi.example.com.      A       10.0.12.99
     chi.example.com.      DHCID   AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdWL3b/NaiUDlW2No=

Example 3:
     chi6.example.com.     AAAA    2000::1234:5678
     chi6.example.com.     DHCID   AAIBY2/AuCccgoJbsaxcQc9TUapptP69lOjxfNuVAA2kjEA=

When calculating the SHA-256 hash, the following data patterns were used:

unsigned char example_1_data[] = {
	0x01,								// ethernet type code
	0x01, 0x02, 0x03, 0x04, 0x05, 0x06,			// mac address
	6, 'c', 'l', 'i', 'e', 'n', 't',
	7, 'e', 'x', 'a', 'm', 'p', 'l', 'e',
	3, 'c', 'o', 'm',
	0 };

unsigned char example_2_data[] = {
	0x01, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c,		// client identifier
	3, 'c', 'h', 'i',
	7, 'e', 'x', 'a', 'm', 'p', 'l', 'e',
	3, 'c', 'o', 'm',
	0 };

unsigned char example_3_data[] = {
	0x00, 0x01, 0x00, 0x06, 0x41, 0x2d, 0xf1, 0x66,	// DUID
	      0x01, 0x02, 0x03, 0x04, 0x05, 0x06,
	4, 'c', 'h', 'i', '6',
	7, 'e', 'x', 'a', 'm', 'p', 'l', 'e',
	3, 'c', 'o', 'm',
	0 };

Before base64 encoding, the 2 octet identifier type and 1 octet digest type (=1) were added in front of  the resulting SHA-256 hash.

- Bernie

> From: Bernie Volz (volz) 
> Sent: Saturday, February 25, 2006 1:49 PM
> To: Ólafur Guðmundsson /DNSEXT co-chair
> Cc: [email-masked]; [email-masked]; Sam 
> Hartman; [email-masked]
> Subject: RE: [dhcwg] Open issues in DHCP FQDN,DHCID and 
> DDNS-DHCP Related RFCs
> 
> I figured I'd wait until we settled on whether this was the 
> correct way to go before supplying the DHCID RR data for the 
> 3 examples. (I also didn't have a SHA-256 implementation 
> readily at hand to actually write a quick program but 
> implementations are readily available, such as in the OpenSSL 
> distribution. I wanted to get the updated draft out figuring 
> that the examples can be handled during the RFC editing process.)
> 
> - Bernie
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

---

From: Mark Stapp <[email-masked]>
Date: Mon, 27 Feb 2006 10:11:29 -0500

Olafur,

I computed the sha256 hashes this morning using python 2.4 and the 
Crypto.SHA256 module, and got the same DHCID data for the three 
examples. I didn't think it would be necessary to post a transcript of 
the python command-lines or a script, but I could do that if you think 
it's helpful.

-- Mark