On Sat, 12 Mar 2005, Alex Bligh wrote:

> --On 12 March 2005 18:10 +0100 Roy Arends wrote:
> > Rolling hash algorithms (from mandatory to optional) is problematic, as
> > was previously shown on this list. Since there is also no real profit in
> > supporting more then one algorithm, we can obsolete the algorithm
> > field from the RDATA, and settle on a single algorithm for nsec3: SHA-224
> > (rfc-3874).
> >
> > Any comments ?

> I suggest using a longer algorithm (SHA-512), and then specifying a
> variable number of bits to truncate to, to enable the signer to achieve
> their own balance between non-enumerability and minimization on-wire
> packet size. For small zones, this could be less than traditional NSEC
> if people don't care about enumerability (if we make sure we treat
> weak hash algorithms right).

A label has a maximum length of 63 characters. With base-32, the maximum
amount of bits we could squeeze in a label is 315. So, truncation is
definitly needed for sha-512.

> I also think that those wanting to support weak algorithms, AND those who
> are concerned to treat QNAME/label hash collisions right (despite their
> unlikelihood) AND those who don't give a fig about enumerability and want
> to use minimum CPU cycles will EACH want to support an identity hash
> algorithm.

Isn't using identity hash effectively similar as using NSEC ?


to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.