Subject: [Anima] Section 6.10.2 of draft-ietf-anima-autonomic-control-plane

From: William Atwood <[email-masked]>
Date: Sat, 4 Nov 2017 13:43:54 -0400

Para 2, bullet 2, says the following:

"The 40 bits ULA "global ID" (term from [RFC4193]) for ACP
addresses carried in the domain information field of domain
certificates are the first 40 bits of the SHA256 hash of the
routing subdomain from the same domain information field. In the
example of Section 6.1.1, the routing subdomain is
"area51.research.acp.example.com" and the 40 bits ULA "global ID"
a379a6f6ee."

Since I wanted to see what the SHA256 hash would be for an Autonomic 
Network that I plan to create in my lab, I went looking for SHA256 hash 
generators on-line.

For two different on-line generators, I get the following results:

http://www.xorbin.com/tools/sha256-hash-calculator
area51.research.acp.example.com
89b714f3db8e41558cfb49d4d763ee7cc5ae53a3ffe8a17039679d06dc9bb0e3

http://passwordsgenerator.net/sha256-hash-generator/
area51.research.acp.example.com
89B714F3DB8E41558CFB49D4D763EE7CC5AE53A3FFE8A17039679D06DC9BB0E3

These give identical results, but the first 40 bits have no (apparent) 
relationship with the result cited in the ACP draft.

Does anyone have any idea which one is wrong, and why?

   Bill

-- 
Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
    and Software Engineering
Concordia University EV 3.185     email:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: William Atwood <[email-masked]>
Date: Sun, 5 Nov 2017 21:00:31 -0500

Supplementary question:

Is the change from SHA-1 (in RFC 4193) to SHA256 (in this draft) 
intentional?  If so (and I presume that it is, given that SHA-1 seems to 
be in disrepute), then the statements in Section 6.10.2 of the ACP document:

"The first 48 bits follow the ULA scheme, as defined in [RFC4193], to 
which a type field is added:"

will have to be altered to note the change from SHA-1 to SHA256.

   Bill

-------- Forwarded Message --------
Subject: [Anima] Section 6.10.2 of draft-ietf-anima-autonomic-control-plane
Date: Sat, 4 Nov 2017 13:43:54 -0400
From: William Atwood <[email-masked]>
To: [email-masked]

   Bill

_______________________________________________
Anima mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 6 Nov 2017 15:11:00 +1300

> will have to be altered to note the change from SHA-1 to SHA256.

Note that there aren't any normative keywords applied to the choice
of SHA-1 in RFC4193, so I don't think this is a normative update.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 Nov 2017 10:57:32 -0500

> 89b714f3db8e41558cfb49d4d763ee7cc5ae53a3ffe8a17039679d06dc9bb0e3

Sometimes the difference is whether or not a CR and/or LF is included in the
hash.  I see that your result is without the line feed.

dooku-[~](2.3.0) mcr 14553 %echo area51.research.acp.example.com | sha256sum
60b1547f399cb8354010e0bd5853f0bcd393590e44efa2cb47c233615e9ce766  -
dooku-[~](2.3.0) mcr 14554 %echo -n area51.research.acp.example.com | sha256sum
89b714f3db8e41558cfb49d4d763ee7cc5ae53a3ffe8a17039679d06dc9bb0e3  -

But, the only device that needs to create the ULA prefix is the registrar
during it's bootstrap, and once created it is to be stored.  I would expect
that if there was an administrator interface that it would ask for some
domain details, and then pre-populate a "ACP prefix" field with the result,
but let the admin type in their own.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: William Atwood <[email-masked]>
Date: Mon, 6 Nov 2017 12:23:06 -0500

Michael,

My point is not in how the hash is used, but that the example is wrong.

Neither sha1sum nor sha256sum gives "a379a6f6ee" as the first 40 bits.

poise bill > echo -n area51.research.acp.example.com | sha1sum
78145a90f86c6a7c7a92605b67a5d9373bde0fae  -

Therefore, since neither my sha256sum result nor my sha1sum result is 
the same as the example, and since you have verified that my sha256sum 
result is correct (and the draft calls for a sha256sum result), the 
result in the example is wrong, and needs to be corrected.

   Bill

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Nov 2017 08:23:19 +1300

> My point is not in how the hash is used, but that the example is wrong.

Yes. The value has been there since draft -08 and it's been wrong all along.
 
> Neither sha1sum nor sha256sum gives "a379a6f6ee" as the first 40 bits.

Nor does MD5, which was specified in earlier versions of the draft.

(The text makes it clear that it's the raw name that is hashed, so including
LF, CR or both would be wrong.)

    Brian