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

From: Wes Hardaker <[email-masked]>
Date: Wed, 09 Feb 2022 13:11:44 -0800

Petr Špaček <[email-masked]> writes:

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

Sentence added -- seems wildly agreed upon.
-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 09 Feb 2022 13:14:47 -0800

Matthijs Mekking <[email-masked]> writes:

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

Whoops, good catch thanks.
-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 09 Feb 2022 13:33:20 -0800

Petr Špaček <[email-masked]> writes:

> I believe that this property renders salt practically useless, so let
> me propose a modified section 2.4:

[snip]

Thanks for the text and it seems well agreed upon, so I replaced section
2.4 with your text after making some editing related tweaks.  Feel free
to re-read it and tell me any of my edits were incorrect or changed the
meaning :-)

-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 09 Feb 2022 13:33:48 -0800

Matthijs Mekking <[email-masked]> writes:

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

Thanks for the good text Matthijs.  I've added it tot he bottom of the
existing 3.2, which seems to be where consensus indicated it should go.
-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 09 Feb 2022 13:34:51 -0800

Paul Vixie <paul=[email-masked]> writes:

> 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

Good catch; I've changed all references.
-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 09 Feb 2022 13:41:41 -0800

Vladimír Čunát <[email-masked]> writes:

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

So I've re-arranged things a bit to hopefully address the flow better.
Let em know if you think further improvements are warranted.
-- 
Wes Hardaker
USC/ISI

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 22 Feb 2022 12:29:21 +0100

> Let em know if you think further improvements are warranted.

I'd still probably suggest at least a minimalist change like:
-Note that a validating resolver MUST still validate the signature
+Note that a validating resolver returning an insecure response MUST 
still validate the signature

But to me it's certainly not a big deal.  (Though not changing this 
would mean that formally I wouldn't be exactly following the RFC.)

--Vladimir

---

From: Geoff Huston <[email-masked]>
Date: Tue, 22 Feb 2022 19:02:59 +0000

> On 22 Feb 2022, at 10:29 pm, Vladimír Čunát <[email-masked]> wrote:
> 
> +Note that a validating resolver returning an insecure response MUST still validate the signature

Hi Vladimir,

I’m not sure I follow that latter comment relating to "a validating resolver returning an insecure response" - Do you mean:

a) - a DNSSEC-validation capable resolver responding to a query that had the CD bit set?

b) - a DNSSEC-validation capable resolver responding to a query that had no EDNS(0) extensions at all?

c) - a DNSSEC-validation capable resolver responding to a query that received an NSEC record signed with an algorithm, that was not recognised by the resolver?

Geoff

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 22 Feb 2022 23:56:30 +0100

> c) - a DNSSEC-validation capable resolver responding to a query that received an NSEC record signed with an algorithm, that was not recognised by the resolver?

Oh, I'm sorry, I thought it would be perfectly clear in the context of 
this previous e-mails in this thread and the draft's paragraphs directly 
preceding the diff I posted.

Anyway, let me explain why our current code would violate the text but 
not the intent (or security properties).  It's about the "may SERVFAIL" 
case, defined as
 > Validating resolvers MAY also return SERVFAIL when processing NSEC3 
records with iterations larger than 0.

I believe that the cleanest and least bug-prone way to implement this 
sub-case is to simply ignore any NSEC3 records with iterations over the 
limit.  You do not need to check any kind of signatures or any further 
properties, as it's just trading one SERVFAIL for another SERVFAIL.  
(OK, maybe the EDE code or similar diagnostics could suffer a little, 
but I'm not convinced the complications are worth it.)  Now, this 
implementation approach would get into conflict with that sentence:
 > Note that a validating resolver MUST still validate the signature

so I was trying to suggest a simple way of patch it up to avoid 
colliding with the implementation approach that I find useful.  I don't 
really care about particular formulation, but I'd find it a bit 
unfortunate if I had to choose between not strictly following the RFC or 
complicating the implementation (unnecessarily in my view).

I hope I've stated my argument clearly now.  Thanks for bearing with me.
--Vladimir

---

From: Paul Vixie <[email-masked]>
Date: Tue, 22 Feb 2022 16:12:33 -0800

Vladimír Čunát wrote on 2022-02-22 14:56:
>> ...
> properties, as it's just trading one SERVFAIL for another SERVFAIL. ... 
> 

+1.

-- 
P Vixie

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 25 Feb 2022 15:30:23 -0800

Vladimír Čunát <[email-masked]> writes:

> But to me it's certainly not a big deal.  (Though not changing this would mean that
> formally I wouldn't be exactly following the RFC.)

I think there seems to be consensus about this, so I implemented your
change.

I think it's actually best to be as clear as possible as what's
acceptable.  IE, you shouldn't be trying to find hidden loopholes.  So I
added this:

Validating resolvers MAY choose to not respond to NSEC3 records with
iterations larger than 0.

-- 
Wes Hardaker
USC/ISI