Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

[Petr Špaček <[e-mail]>]

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:
>> [e-mail] 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