Re: [dnsext] NSEC4

Matthijs,

--On 4 January 2012 12:06:02 +0100 Matthijs Mekking <matthijs@NLnetLabs.nl> 
wrote:

> First of all, you mentioned that the "no hash" (or "zero hashing") was
> also discussed during the development of NSEC3. Unfortunately, it is
> hard (if not impossible) to define it as a new NSEC3 hash function:

Uggghh. If true, that is a shame.

> For
> "zero hashing" the Next (Hashed) Owner Name field cannot be base32
> encoded. Therefore, with our experiment we made the field a Domain Name.

I /think/ your explanation could be clarified a little. If I understand
things correctly, the issue is not that the Next (Hashed) Owner Name cannot
be base32 encoded (it isn't - it's in binary - see 3.1.6, 3.1.7 and the
last para of 3.2 of the RFC), but that the owner name of the NSEC3 RR needs
to be equal to the base32 encoded value of the previous Next (Hashed) Owner
Name, and as such cannot be guaranteed to fit in the Owner Name.

What we should have done is defined that mapping (base32 encoding here) as
part of the hash algorithm. What we also should have done is specified the
identity mapping as part of the standard. NSEC3 fatigue as someone said.

Unless I'm missing something, the Next (Hashed) Owner Name it seems to me
could be base32 encoded, provided that the encoded value does not exceed
255 bytes. I think that allows representation of up to 159 characters,
which might be useful to someone.

But I seem to remember that hash algorithm support signaling is a minefield
anyway.

-- 
Alex Bligh
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext