[dns-operations] Evaluation of NSEC3-encloser attack

Viktor Dukhovni ietf-dane at dukhovni.org
Wed Mar 27 19:55:10 UTC 2024


On Wed, Mar 27, 2024 at 07:17:01PM +0000, Matthew Richardson via dns-operations wrote:

> Viktor Dukhovni wrote:-
> 
> >I do hope that, as a community, we'll continue to steadily streamline
> >acceptable NSEC3 parameters (per RFC9276) down to 0 additional
> >iterations and short enough salt values (that don't result in additional
> >SHA-1 input blocks).
> 
> What would be the largest salt length to ensure that such additional input
> blocks are not required?

The SHA-1 hash function "comresses" 64 bytes of input (a 512-bit block)
to 20 bytes of output, 8 of the trailing input bytes are a 64-bit
message length, and there's at least 1 byte (0x80) of padding.

    https://datatracker.ietf.org/doc/html/rfc3174#section-4

Whether additional SHA-1 blocks are required depends on the length of
the owner-name:

    https://datatracker.ietf.org/doc/html/rfc5155#section-5

If the owner name and salt fit into 55 bytes, a single SHA-1 block would
be sufficient, otherwise a second or more SHA-1 block may be required.
Worst case is 255 bytes of owner name (wire form) + 255 bytes of salt,
which would require 9 SHA-1 blocks.

With a zero length salt, one gets to hash 55 bytes of owner-name in a
single SHA-1 block.

-- 
    Viktor.


More information about the dns-operations mailing list