Subject: Re: nsec2 large label pain

From: Marcos Sanz/Denic <[email-masked]>
Date: Mon, 24 May 2004 16:28:48 +0200

> There are other obstacles as well. Current label length restricts the
> message digest size (if represented in hex) to 248 bits. This excludes
> functions like sha-256/384/512.

If we forget hex (with a byte-utilization rate of 50%) and do kind of 
base64 (75%), then sha-256 can still be used.

Regards,
Marcos

--
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: Peter Koch <[email-masked]>
Date: Mon, 24 May 2004 16:33:49 +0200

[email-masked] wrote:

> There are several ways to 'fix this', including a new label type (type
> HASH or something evil) if you like.

this rings the complexity bell, but see below[*].

> message digest size (if represented in hex) to 248 bits. This excludes
252?

> functions like sha-256/384/512.

First of all, is it really necessary to have so "wide" fingerprints or isn't
the goal better achieved otherwise? Even with a more efficient encoding
(now's time again for the 8 bit debate ...) you'd end up with no more than
504 bits in a label. Practical considerations might lead to a 5/8 encoding,
using e.g. A-Z0-5, large enough for 256 bit. But then, why should the hash
be restricted to one label only, other than that longer hashes restrict
the overall available length of the zone name?

[*] The "new" label type could be bitstring (RFC 2673) or something similar.
This would solve one anomaly of the current proposal: owner names of NSEC2
RRs are names that exist in the zone, but their non-existence is proven
by those NSEC2 RRS, too (not necessarily by the one they own, but by others).
If bitstring labels were used this would open up a "shadow namespace", so
hash owners wouldn't conflict with what they're trying to prove.
For similar reasons the NO draft moved the hashes to a subdomain, IIRC.

-Peter

PS: The draft doesn't yet specify exactly how the hash is calculated and
    how to apply the seed. I'd guess that the seed - if any - needs to be
    used twice, like in HMAC.