Subject: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

From: [email-masked]
Date: Wed, 24 Nov 2021 08:59:11 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        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

Abstract:
   NSEC3 is a DNSSEC mechanism providing proof of non-existence by
   promising there are no names that exist between two domainnames
   within a zone.  Unlike its counterpart NSEC, NSEC3 avoids directly
   disclosing the bounding domainname pairs.  This document provides
   guidance on setting NSEC3 parameters based on recent operational
   deployment experience.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec3-guidance/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-nsec3-guidance-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec3-guidance-02

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 24 Nov 2021 09:02:24 -0800

> 	Filename        : draft-ietf-dnsop-nsec3-guidance-02.txt

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.
-- 
Wes Hardaker
USC/ISI

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 25 Nov 2021 09:33:09 +0100

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?

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.

3.2.  Recommendation for validating resolvers

    Validating resolvers returning an insecure or SERVFAIL answer because
    of unsupported NSEC parameter values SHOULD return an Extended DNS
    Error (EDE) EDNS0 option of value.

I believe this should be NSEC3 parameter values here (instead of NSEC).

4.  Security Considerations

I appreciate that you added the reasoning for lowering the acceptable 
iteration counts here and in section 3.2 but I miss the argument for not 
lowering. Suggested text:

    On the other hand, zones that are still using high iteration counts
    may become unreachable on some parts of the network when a resolver
    decides to return SERVFAIL above a higher point. Before lowering the
    acceptable iteration count, resolver operators and resolver software
    vendors are encouraged to monitor the used iteration counts and reach
    out to zone publishers to implement this document by setting the
    iteration count to 0.

Appendix E.  Implementation Notes

Note that BIND 9.16.16 and up will treat DNSSEC responses containing 
NSEC3 records with iteration counts greater than 150 are now treated as 
insecure, and the maximum supported number of NSEC3 iterations that can 
be configured for a zone has been reduced to 150.

Best regards,

Matthijs

---

From: Petr Špaček <[email-masked]>
Date: Thu, 25 Nov 2021 13:00:33 +0100

> Or is there a valid reason for zone publishers to set iterations to a 

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.
----------

> 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.

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

---

From: Paul Vixie <[email-masked]>
Date: Thu, 25 Nov 2021 09:12:58 -0800

Petr Špaček wrote on 2021-11-25 04:00:
>> ...
>> ...

+1.

>>> ...
>>>>     ...
>>> ...
> ...

+1.

> justification and I don't want to drown the important piece of 

+1.

vixie

-- 
Sent from Postbox
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 26 Nov 2021 09:43:00 +0100

> Honestly I can't see anything more specific which will not get out of 

Can we make use of the keyword MAY? This allows I think for text that 
will not get out of date:

    Validating resolvers MAY return an insecure response when processing
    NSEC3 records with iterations larger than 0. Validating resolvers MAY
    also return SERVFAIL when processing NSEC3 records with iterations
    larger than 0. This significantly decreases the requirements
    originally specified in Section 10.3 of [RFC5155]. See the Security
    Considerations for arguments on how to handle responses with non-zero
    iteration count.

Having text that says "MAY do this at value X" is more quantifiable and 
IMO a stronger signal that zone publishers really should not use value X.

Best regards,

Matthijs

---

From: Petr Špaček <[email-masked]>
Date: Fri, 26 Nov 2021 10:24:48 +0100

> IMO a stronger signal that zone publishers really should not use value X.

Yes, I like this!

Maybe your proposed text can be prepended/appended to the current 
content of 3.2.  Recommendation for validating resolvers, so we can keep 
the "vendors are encouraged to continue evaluating NSEC3 iteration count 
deployments" part?

-- 
Petr Špaček

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 26 Nov 2021 11:49:03 +0100

On 25/11/2021 13.00, Petr Špaček wrote:
> 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. 

I disagree; you don't need to rotate so fast.  At a moment when a 
particular salt won't be contained in future answers, there's no point 
in creating a dictionary anymore as it's cheaper to crack the gathered 
hashes individually.  The only value of dictionary is (possibly) 
speeding up attacks on names that will appear in future - and the only 
value in re-salting is in making this technique more expensive.  
Resalting interval is the period when a particular dictionary is useful, 
so basically by halving the interval you double the price of this.  [all 
IMHO]

--Vladimir

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 26 Nov 2021 12:30:07 +0100

I like the text and how it's improving.

> Note that a validating resolver MUST still validate the signature over 
> the NSEC3 record to ensure the iteration count was not altered since 
> record publication (see {{RFC5155}} section 10.3).
>
It might be better to clarify that this "MUST" does not really apply to 
the SERVFAIL case.  (The text around has changed recently.)

I think this SERVFAIL will generally be best implemented by simply 
ignoring any NSEC3 above the corresponding limit.  Maybe I'd even 
standardize the case that way, but I don't care really. It's an 
advantage unstated in the draft that this is very easy to do, leaving no 
room for bugs (e.g. unintentional downgrade opportunities).

--Vladimir

---

From: Petr Špaček <[email-masked]>
Date: Fri, 26 Nov 2021 12:32:19 +0100

> so basically by halving the interval you double the price of this.  [all 

You are right right, I did not consider "crack names which do not exist 
yet" scenario and focused only on dictionary reuse across zones.

Do you have specific proposals for draft text?

Also, when we are theorizing, we can also consider that resalting 
thwarts simple correlation: After a resalt attacker cannot tell if a set 
of names has changed or not. With a constant salt attacker can detect 
new and removed names by their hash. (I'm not sure it is useful 
information without cracking the hashes.)

-- 
Petr Špaček

---

From: Paul Vixie <[email-masked]>
Date: Fri, 26 Nov 2021 11:13:13 -0800

> the "vendors are encouraged to continue evaluating NSEC3 iteration count 

if we must say this, s/vendors/implementers/, please. some of us when we 
play with dns or dnssec don't share our resulting code. --vixie

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 27 Nov 2021 01:12:57 -0500

> information without cracking the hashes.)

Actually, no.  If one has previously been mostly successful at cracking
extant names in a zone, rehashing of a small set (much smaller than the
full dictionary one use) of known names is rather quick.  So old names
can be quickly identified even after a salt change.  Leaving just the
hashes of new names.

Mind you, for cracking the new names, one would still rehash the entire
dictionary when the salt changes, the number of new names to check is
not a scaling factor in the cost.  Just a table join.

So periodic resalting does raise the cost of ongoing tracking of a
zone's content, if that's the sort of thing one cares enough about.
Rarely worth it, but mostly harmless if the salt is not too long and
rotated say on each ZSK rollover.

-- 
    Viktor.

---

From: Petr Špaček <[email-masked]>
Date: Mon, 29 Nov 2021 18:40:58 +0100

> can be quickly identified even after a salt change.  Leaving just the

To be clear: I was talking about attacker who does not cracked the zone. 
You are right that rehashing know names is very cheap.

> rotated say on each ZSK rollover.

Plus all the mess with large zone transfers, which often can cause 
issues, especially when done in huge batches (like rotating ZSK/salt 
shared for 100 000 zones on a shared hosting.)

-- 
Petr Špaček

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 30 Nov 2021 10:16:26 +0100

On 26/11/2021 12.32, Petr Špaček wrote:
> You are right right, I did not consider "crack names which do not 
> exist yet" scenario and focused only on dictionary reuse across zones.
>

No, I don't have any ideas for improvements.  The current salt section 
reads nice to me.

--Vladimir