--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).

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 namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.