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

[Paul Vixie <[e-mail]>]

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>