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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
