This is a discussion on Re: nsec3 with one hash algorithm: SHA-224 - DNS ; --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 ...
--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
> 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).
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. That means you need the field anyway (conceivably it
could be 0 for identity, or a number of octets to which SHA-512 is
My personal view on the necessity for identity algorithm is that it's
only needed if you want to support weak / deliberately over truncated
hash algorithms, but I understand others' points of view.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.