On 25. 11. 21 9:33, Matthijs Mekking wrote:
Hi Wes,
I think the changes are moving the document in the right direction.
Some comments:
3.1. Best-practice for zone publishers
I wonder if we can make the requirement even stronger by saying "If
NSEC3 must be used, then an iterations count of 0 MUST be used to
alleviate computational burdens." (MUST instead of SHOULD).
Or is there a valid reason for zone publishers to set iterations to a
non-zero value?
This section is IMHO missing a scary warning to explain the reasons. Let
add one couple sentences (+ "extra" keyword to differentiate it from the
implicit single iteration):
----------
If NSEC3 must be used, then an extra iterations count of 0 SHOULD be
used to alleviate computational burdens.
Please note that extra iteration counts other than 0 increase impact of
resource CPU-exhausting DoS attacks, and also increase risk of
interoperability problems.
----------
3.2. Recommendation for validating resolvers
I understand why the new text is here, but I think this now actually
gives too little advice for operators and vendors.
I know, this is a vague comment, I need to think about it a bit more.
Honestly I can't see anything more specific which will not get out of
date quickly.
On 24-11-2021 18:02, Wes Hardaker wrote:
internet-dra...@ietf.org writes:
Title : Guidance for NSEC3 parameter settings
Authors : Wes Hardaker
Viktor Dukhovni
Filename : draft-ietf-dnsop-nsec3-guidance-02.txt
Pages : 10
Date : 2021-11-24
This version attempts to take into account the discussion from the WG
meeting at IETF 112. Concrete text proposals appreciated so we can
finish this work and publish it.
I have an additional comment for section 2.4:
> 2.4. Salt
> Salts add yet another layer of protection against offline, stored
> dictionary attacks by combining the value to be hashed (in our case,
> a DNS domainname) with a randomly generated value. This prevents
> adversaries from building up and remembering a dictionary of values
> that can translate a hash output back to the value that it derived
> from.
It seems to me that this into paragraph basically contradicts rest of
the section which goes on and explains why extra salting is not
necessary... but see below.
IMHO in the context of NSEC3 the salt would make sense _only_ if it were
rotated faster than attacker was able to walk the zone. Once attacker
has list of hashes available for offline cracking the salt does not do
anything useful anymore.
Even relatively big zones with say 1M names can be walked within a
single day without raising alarms because nobody would notice 12 queries
per second (1000000/86400 qps), and I seriously doubt anyone with 1M
names is rotating salt faster than within one day.
I believe that this property renders salt practically useless, so let me
propose a modified section 2.4:
------------
NSEC3 records provide an an additional salt value, which can be
combined with FQDN to influence the resulting hash, but properties of
this extra salt are complicated.
In the cryptography field, salts generally add a layer of protection
against offline, stored dictionary attacks by combining the value to be
hashed with a unique "salt" value. This prevents adversaries from
building up and remembering a single dictionary of values that can
translate a hash output back to the value that it derived from.
In the case of DNS, the situation is different because the hashed
names placed in NSEC3 records are always implicitly "salted" by hashing
the fully-qualified domain name from each zone. Thus, no single
pre-computed table works to speed up dictionary attacks against multiple
target zones. An attacker is always required to compute a complete
dictionary per zone, which is expensive in both storage and CPU time.
To understand role of the additional NSEC3 salt field, we have to
consider how a typical zone walking attack works. Typically the attack
has two phases - online and offline. In the online phase, an attacker
"walks the zone" by enumerating (almost) all hashes listed in NSEC3
records and storing them for offline cracking. Then in the offline
phase, the attacker attempts to crack the underlying hash. In this case,
the additional salt value can raise cost of the attack only if the salt
value changes during the online phase of the attack. In other words, a
additional salt value which is constant during the online phase of the
attack does not change cost of the attack.
Changing a zone's salt value requires the construction of a complete
new NSEC3 chain. This is true both when resigning the entire zone at
once, or incrementally signing it in the background where the new salt
is only activated once every name in the chain has been completed. As a
result, re-salting a is very complex operation, with significant CPU
time, memory, and bandwidth consumption. This makes very frequent
re-salting unpractical, and renders the additional salt field almost
useless.
Operators are encouraged to forget the salt entirely by using a
zero-length salt value instead (represented as a "-" in the presentation
format).
------------
I'm tempted to put the last paragraph first, because all the rest is
justification and I don't want to drown the important piece of
information in it.
--
Petr Špaček
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
