Subject: [DNSOP] Any suggestion on what I'm doing that is stupid here on NSEC3?

From: Nicholas Weaver <[email-masked]>
Date: Wed, 12 Feb 2014 07:35:47 -0800

I'm trying to do my own implementation of NSEC3 as part of my dynamic DNSSEC server (in order to do NSEC3 lies for NXDOMAIN, since you can't do such a lie with NSEC, NSEC lies only allow "0 answer noerror" which is unfortunately NOT the same)

But I appear to be doing something stupid, and am not operating the hash right:

Looking at com, the NSEC3 for "com" is:
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - ...

(Algorithm 1 -> SHA-1, flag = 1, iterations = 0, salt = None, fetched by "dig +dnssec MX com @a.gtld-servers.net")

Reading RFC5155, the calculation of the hash is:

>    The hash calculation uses three of the NSEC3 RDATA fields: Hash
>    Algorithm, Salt, and Iterations.
> 
>    Define H(x) to be the hash of x using the Hash Algorithm selected by
>    the NSEC3 RR, k to be the number of Iterations, and || to indicate
>    concatenation.  Then define:
> 
>       IH(salt, x, 0) = H(x || salt), and
> 
>       IH(salt, x, k) = H(IH(salt, x, k-1) || salt), if k > 0
> 
>    Then the calculated hash of an owner name is
> 
>       IH(salt, owner name, iterations),
> 
>    where the owner name is in the canonical form, defined as:
> 
>    The wire format of the owner name where:
> 
>    1.  The owner name is fully expanded (no DNS name compression) and
>        fully qualified;
> 
>    2.  All uppercase US-ASCII letters are replaced by the corresponding
>        lowercase US-ASCII letters;
> 
>    3.  If the owner name is a wildcard name, the owner name is in its
>        original unexpanded form, including the "*" label (no wildcard
>        substitution);

So it should be the base32 encoding of the SHA1 hash of the wire format for "com" (since there is no salt), which in python is:

"\x03com\x00", (3 characters, the string "com", and 0 as a terminator in wire format.  This matches the wire format I get from my name packer in my DNS server)

Yet when I try to calculate the SHA1 hash in python's library, I get:
>>> m = hashlib.sha1() 
>>> m.update("\x03com\x00") # There is no salt and 0 additional iterations
>>> base64.b32encode(m.digest()) 
'MUAZYTWQIHEVT3OPHOPXIEDA27S5IL4W'
>>> m.hexdigest()
'65019c4ed041c959edcf3b9f741060d7e5d42f96'

But at the same time, this matches the sha1sum for a file containing just the string "\x03com\x00", so the hash is correct for sha1.

So the conclusion is I'm not putting in the right input into the hash function.  Thoughts on what I'm doing wrong?

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Shumon Huque <[email-masked]>
Date: Wed, 12 Feb 2014 10:57:09 -0500

It might be because NSEC3 uses base32 with extended hex alphabet.
Looks like you're using plain base32.

See http://tools.ietf.org/html/rfc4648#section-7

--Shumon.

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Shumon Huque
University of Pennsylvania.

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 12 Feb 2014 21:39:24 +0530

Hi Nicholas

On Wed, Feb 12, 2014 at 07:35:47AM -0800, Nicholas Weaver wrote:
> [snip]
> So it should be the base32 encoding of the SHA1 hash of the wire
> format for "com" (since there is no salt), which in python is:
> 
> "\x03com\x00", (3 characters, the string "com", and 0 as a terminator
> in wire format.  This matches the wire format I get from my name
> packer in my DNS server)
> 

This is where the problem is. NSEC3 uses base32hex encoding, not
base32. See the difference in RFC 4648 section 7. It should be trivial
to convert the output of the above b32encode() to the base32hex encoding
using a simple lookup map.

If you want to look at some C++ code, clone the BIND 10 repo and look at
the following files:

src/lib/dns/nsec3hash.{h,cc}
src/lib/util/encode/base32hex.h
src/lib/util/encode/base_n.cc

I suggest avoiding the last file and just doing your own base64hex
implementation.. it can make you upset. ;)

		Mukund

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 12 Feb 2014 08:46:28 -0800

Thanks.  Indeed I was stupid: wrong base32 encoding....