Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

[Paul Wouters <[e-mail]>]

On Wed, 17 Feb 2010, Olaf Kolkman wrote:

>   Though all agree DNS data should be accessible through query
>   mechanisms, a side effect of NSEC is that it allows the contents of a
>   zone file to be enumerate in full by sequential query.  Whilst for

Small typos: "enumerated" and "sequential queries"

I am not sure about the "should" in that sentence either. How about "is
accessable through query mechanisms"?


>   delegations).  NSEC3 allows intervals between two such delegations to
>   "Opt-out" in which case they may contain one more more insecure
>   delegations, thus reducing the size and cryptographic complexity of
>   the zone.

"at the expense of some deniability"? I feel we need to make it clear
here that there is a trade-of. Opt-out isn't all positive. It has a
price.

> 5.2.  NSEC or NSEC3
>
>   The first reason to deploy NSEC3, prevention of zone enumeration,
>   makes sense when zone content is not highly structured or trivially

"only makes sense" ?

> 5.3.  NSEC3 parameters
>
>   The NSEC3 hashing includes the FQDN in its uncompressed form.  This

"over its uncompressed form"? The hash does not 'include' it.

> 5.3.1.  NSEC3 Algorithm
>
>   The NSEC3 algorithm is specified as a version of the DNSKEY
>   algorithm.  The current options are:
>
>   Algorithm 6,  DSA-NSEC3-SHA1 is an alias for algorithm 3, DSA.
>
>   Algorithm 7,  RSASHA1-NSEC3-SHA1 is an alias for algorithm 5,
>      RSASHA1.
>
>   The algorithm choice therefor depends solely on the DNSKEY algorithm
>   picked.

"The next record algorithm choice therefor....." to make it less confusing?

> 5.3.3.  NSEC3 Salt
>
>   The salt with NSEC3 is not used to increase the work required by an
>   attacker attacking multiple domains, but as a method to enable
>   creating a new set of hash values if at some point that might be
>   required.  The salt is used as a "roll over".

I would throw this around. Don't start saying what the salt is not for,
but say what it is for. First:

    Key rollovers limit the amount of time attackers can spend on
    attacking a certain key before it is retired.  The salt serves the
    same purpose for the hashes, which are independant of the key being
    used, and therefor do not change when rolling over a key.  Changing
    the salt would cause an attacker to lose all precalculated work for
    that zone.

And then:

   The FQDN RRlabel,
    which is part of the value that is hashed, already ensures that brute
    force work for one RRlabel can not be re-used to attack other RRlabel
    due to their uniquenes.

>   The salt of all NSEC3 records in a zone needs to be the same.  Since
>   changing the salt requires the NSEC3 records to be regenerated, and
>   thus requires generating new RRSIG's over these NSEC3 records, it is
>   recommended to only change the salt when changing the Zone Signing
>   Key, as that process in itself already requires all RRSIG's to be
>   regenerated.

Should there be any explanation about the NSEC3PARAM record here?

>   The Opt-Out mechanism was introduced to allow for a gradual
>   introduction of signed records in zones that contain mostly
>   delegation records.  The use of the OPT-OUT flag changes the meaning
>   of the NSEC3 span from authoritative denial of the existence of names
>   within the span to a proof that DNSSEC is not available for the
>   delegations within the span.  [Editors Note: One could make this
>   construct more correct by talking about the hashed names and the
>   hashed span, but I believe that is overkill].

If you think of protecting typosquatting domain spoofs, it might be important
to realise that the span is over hashes, and not over "most domains that
resemble your domain"?

Paul