Petr Špaček wrote on 2021-11-25 04:00:
On 25. 11. 21 9:33, Matthijs Mekking wrote:
...
3.1. Best-practice for zone publishers
...
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.
----------
+1.
On 24-11-2021 18:02, Wes Hardaker wrote:
...
Title : Guidance for NSEC3 parameter settings
...
Filename : draft-ietf-dnsop-nsec3-guidance-02.txt
Pages : 10
Date : 2021-11-24
...
I have an additional comment for section 2.4:
...
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).
------------
+1.
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.
+1.
vixie
--
Sent from Postbox
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
