This is a discussion on Re: nsec3 with one hash algorithm: SHA-224 - DNS ; 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 ...
On Sat, 12 Mar 2005, Alex Bligh wrote:
> --On 12 March 2005 18:10 +0100 Roy Arends
> > 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
Isn't using identity hash effectively similar as using NSEC ?
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.