nsec3-01 hash truncation for protocol (not crypto) reasons

[Alex Bligh <alex@alex.org.uk>]

I'm going to risk the disapprobation of our esteemed chairs, and talk
about hash truncation. But *NOT* for reasons to do with crypto, for
simple protocol reasons (so I hope I can get away with it).

I think without hash truncation, "long" names just won't work.

For instance, if a "long" (for just about any value of long) hash is used
untruncated (which would seem a good thing) it might be (assuming Base-32,
SHA-224) 45 octets long. But the maximum DNS name length is (IIRC) 254
octets. So if I have (say)

$ORIGIN {20octets}.{63octets}.{63octets}.\
        {63octets}.example.com.

www	IN	A	1.1.1.1

then the total length of the NSEC3 label would be an illegal 225+45=270
octets.

It seems to me the best solution here is to allow truncated hashes, and
make it a rule that the zone signer never constructs NSEC3 records of
illegal length. Here (and apologies for fence-post errors and lack
of caffeine) there are (about) 16 octets worth of space, which in
Base-32 gives a (reasonable) 80 bits worth of hashing.

If one allows hash truncation to a signer-definable number of Base-32
octets (think "string truncation"), then one clearly has at least as many
characters to play with as the longest label within the zone. This will be
provably sufficient even for dense zones if they only use 32 symbols. If
they use more, we still run into problems. For instance, consider a zone
the parent of which is so long that the longest label can only be a single
character. Simply put, there are only 32 possible hash values (as we use
Base-32), but there are at least 38 possible labels (for the purist, 256
possible labels). This implies that if NSEC3 is to be able to sign ALL
zones (and a fallback to NSEC2 is never required), we are also going to
HAVE to implement an identity hash (not for crypto reasons, for protocol
reasons). So in such a zone with 38 labels (that's [a-z0-9\*-]), one cannot
generate an NSEC3 chain at all, even with truncated hash functions. I would
suggest we recommend that NSEC3s for parent zones in excess of (say) 250
octets SHOULD be created with the identity hash anyway. This of course
means they are enumerable.

A corner case I know, but we might as well get it right.

Alex

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>