On Feb 17, 2010, at 4:03 PM, Paul Wouters wrote:
> 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"?
That works for me.
Also, during further editing I have changed the tone of the paragraph a bit:
Instead of "reasons for development" I mention the differences and don't claim
them to be motivations. There are probably many views on the history on how
NSEC3 and OPT-OUT came about and I don;t want to waist time on arguing about
those views on history.
>
>
>> 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.
>
I turned that into:
" at the expense of the abillity to cryptographically deny the existence of
names in a specific span."
>> 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" ?
I think that is right. I cannot come up with occasions whereby those conditions
hold and NSEC3 as a prevention for zone enumeration is still a smart thing to
do.
>
>> 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.
I overlooked this when I copied the text from P.W. who originally supplied it
:-)
How about "hashing algorithm is performed on the FQDN ..."
>
>> 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?
Ack
>> 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.
<pun>
No, you would not, at least you didn't the first time around the initial text
was yours
</pun>
(or am I seriously wrong and acknowledging the wrong person for this
significant contribution?)
> Don't start saying what the salt is not for,
> but say what it is for.
I like this suggestion!
> 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.
I changed the implementation a bit, given the abundant amount of discussion
about key rollovers (which I will try to turn into concrete text) I want to not
make that parallel.
> 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.
I did some editing and rewriting. See the full dump below.
>
> Should there be any explanation about the NSEC3PARAM record here?
Not sure yet, I take WG guidance.
>
>> 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"?
>
I understand what you mean but how important is it to build this argument
comprehensively?
Thanks!!!!
--Olaf
Dump... still work in progress
5. Next Record type
There are currently two types of next records that are provide
authenticated denial of existence of DNS data in a zone.
o The NSEC [4] record builds a linked list of sorted RRlabels with
their record types in the zone.
o The NSEC3 [24] record builds a similar linked list, but uses
hashes instead of the RRLabels.
5.1. Differences between NSEC and NSEC3
The NSEC record requires no cryptographic operations aside from
validating its associated signature record. It is human readable and
can be used in manual queries to determine correct operation. The
disadvantage is that it allows for "zone walking", where one can
request all the entries of a zone by following the next RRlabel
pointed to in each subsequent NSEC record.
Kolkman & Gieben Expires September 8, 2009 [Page 31]
Internet-Draft DNSSEC Operational Practices, Version 2 March 2009
Though all agree DNS data is accessible through query mechanisms, a
side effect of NSEC is that it allows the contents of a zone file to
be enumerated in full by sequential queries. Whilst for some
operators this behaviour is acceptable or even desirable, for others
it is undesirable for policy, regulatory or other reasons. This is
the first difference between NSEC and NSEC3.
The second difference between NSEC and NSEC3 is that NSEC requires a
signature over every RR in the zonefile, thereby ensuring that any
denial of existence is cryptographically signed. However, in a large
zonefile containing many delegations very few of which are to signed
zones, this may produce unacceptable additional overhead especially
where insecure delegations are subject to frequent update (a typical
example might be a TLD operator with few registrants using secure
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 the ability to cryptographically deny the
existence of names in a specific span.
The NSEC3 record uses a hashing method of the requested RRlabel. To
increase the workload required to guess entries in the zone, the
number of hashing iteration's can be specified in the NSEC3 record.
Additionally, a salt can be specified that also modifies the hashes.
Note that NSEC3 does not give full protection against information
leakage from the zone.
5.2. NSEC or NSEC3
The first motivation to deploy NSEC3, prevention of zone enumeration,
only makes sense when zone content is not highly structured or
trivially guessable. Highly structured zones such as the in-
addr.arpa, ip6.arpa and e164.arpa can be trivially enumerated using
ordinary DNS properties while for small zones that only contain
contain records in the APEX and a few common RRlabels such as "www"
or "mail" guessing zone content and proving completeness is also
trivial when using NSEC3.
In those cases the use of NSEC is recommended to ease the work
required by signers and validating resolvers.
For large zones where there is an implication of "not readily
available" RRlabels, such as those where one has to sign an NDA
before obtaining it, NSEC3 is recommended.
The considerations for the second reason to deploy NSEC3 are
discussed below (Section 5.3.4).
Kolkman & Gieben Expires September 8, 2009 [Page 32]
Internet-Draft DNSSEC Operational Practices, Version 2 March 2009
5.3. NSEC3 parameters
The NSEC3 hashing algorithm is performed on the Fully Qualified
Domain Name (FQDN) in its uncompressed form. This ensures brute
force work done by an attacker for one (FQDN) RRlabel cannot be re-
used for another (FQDN) RRlabel attack, as these entries are per
definition unique.
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 next record algorithm choice therefore depends solely on the
DNSKEY algorithm picked.
[Note that there is an issue here as well as mentioned in Section 3.4
regarding RSASSA-PKCS1-v1_5 vs RSASSA-PSS as well as no algorithm
choice for SHA-256]
5.3.2. NSEC3 Iterations
One of the concerns with NSEC3 is that bad actors could perform a
pre-calculated dictionary attack in order to assess if certain domain
names exist within the zones or not. Two mechanisms are introduced
in the NSEC3 specification to increase the costs of such dictionary
attacks: Iterations and Salt.
RFC5155 [24] considers the trade-offs between incuring cost during
the signing process, imposing costs to the validating nameserver,
while still providing a reasonable barrier against dictionary
attacks. It provides useful limits of iterations compared to RSA key
size. These are 150 iterations for 1024 bit keys, 500 iterations for
2048 bit keys and 2,500 iterations for 4096 bit keys. Choosing 2/3rd
of the maximum is deemed to be a sufficiently costly yet not
excessive value.
5.3.3. NSEC3 Salt
While the NSEC3 iterations parameter increases the cost of hashing a
dictionary word, the NSEC3 salt reduces the lifetime for which that
calculated hash can be used. A change of the salt value by the zone
owner would cause an attacker to lose all precalculated work for that
Kolkman & Gieben Expires September 8, 2009 [Page 33]
Internet-Draft DNSSEC Operational Practices, Version 2 March 2009
zone.
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 (e.g. in other domains) due to their uniqueness.
The salt of all NSEC3 records in a zone needs to be the same. Since
changing the salt requires all the NSEC3 records to be regenerated,
and thus requires generating new RRSIG's over these NSEC3 records, it
is recommended to align the change of the salt with a change of the
Zone Signing Key, as that process in itself already requires all
RRSIG's to be regenerated. If there is no critical dependency on
incremental signing and the whole zone can be signed with little
effort there is no need for such alignment.
5.3.4. Opt-out
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]. This allows for the
addition or removal of the delegations covered by the span without
recalculating or re- signing RRs in the NSEC3 RR chain. Opt-Out is
specified to be used only over delegation points and will therefore
only bring relieve in zones with a large number of zones and where
the number of secure delegations is small. This consideration
typically holds for large top-level-domains and similar zones, in
most other circumstances Opt-Out should not be deployed. Further
considerations can be found in RFC5155 section 12.2 [24].
________________________________________________________
Olaf M. Kolkman NLnet Labs
Science Park 140,
http://www.nlnetlabs.nl/ 1098 XG Amsterdam
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
