Subject: Re: [DNSOP] New Version Notification for draft-ietf-dnsop-nsec3-guidance-03.txt

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

[email-masked] writes:

> A new version of I-D, draft-ietf-dnsop-nsec3-guidance-03.txt
> has been successfully submitted by Wes Hardaker and posted to the
> IETF repository.
> 
> Name:		draft-ietf-dnsop-nsec3-guidance
> Revision:	03

Sorry the delay in resolving the discussions in December and getting a
new version out.  January was a very long deadline-month for me.

I believe I've acted on all the recent suggestions (thank you!), and the
document is now pretty much ready for WG last call.  IMHO.
-- 
Wes Hardaker
USC/ISI

---

From: Petr Špaček <[email-masked]>
Date: Thu, 10 Feb 2022 12:59:15 +0100

> document is now pretty much ready for WG last call.  IMHO.

I'm happy with values mentioned in the document, thank you!

I gave it full re-read and there are two more edit proposals, hopefully 
non-controversial:

First, I perceive a "problem" with the current document structure:
>    2.  Recommendation for zone publishers  . . . . . . . . . . . . .   3
>      2.1.  Algorithms  . . . . . . . . . . . . . . . . . . . . . . .   3
>      2.2.  Flags . . . . . . . . . . . . . . . . . . . . . . . . . .   4
>      2.3.  Iterations  . . . . . . . . . . . . . . . . . . . . . . .   4
>      2.4.  Salt  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
>    3.  Recommendations for deploying and validating NSEC3 records  .   6
>      3.1.  Best-practice for zone publishers . . . . . . . . . . . .   6
>      3.2.  Recommendation for validating resolvers . . . . . . . . .   7
>      3.3.  Recommendation for Primary / Secondary relationships  . .   7

It seems odd to have "2. Recommendation for zone publishers" followed by 
"3.1 Best-practice for zone publishers".

Either my understanding of relationship between terms "recommendation" 
vs. "best practice" is wrong, or these should be somehow renamed. Say 
"Background information about NSEC3 parameters" as name of section 2?

Also there is now a SHOULD vs. MUST inconsistency between _content_ of 
sections 2.3. Iterations and section 3.1. Best-practice for zone publishers:

> 2.3.  Iterations
...
>    Although Section 10.3 of [RFC5155] specifies upper bounds for the
>    number of hash iterations to use, there is no published guidance for
>    zone owners about good values to select.  Because hashing provides
>    only moderate protection, as shown recently in academic studies of
>    NSEC3 protected zones [GPUNSEC3][ZONEENUM], this document recommends
>    that zone owners SHOULD use an iteration value of 0 (zero),
>    indicating that only the initial hash value should be placed into a
>    DNS zone's NSEC3 records.

vs.

> 3.1.  Best-practice for zone publishers
> 
>    First, if the operational or security features of NSEC3 are not
>    needed, then NSEC SHOULD be used in preference to NSEC3.  NSEC3
>    requires greater computational power (see Appendix B) for both
>    authoritative servers and validating clients.  Specifically, there is
>    a non trivial complexity in finding matching NSEC3 records to
>    randomly generated prefixes within a DNS zone.  NSEC mitigates this
>    concern.  If NSEC3 must be used, then an iterations count of 0 MUST
>    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.

My proposal to fix that inconsistency is to remove last part of 2.3, 
specifically:
> , this document recommends
>    that zone owners SHOULD use an iteration value of 0 (zero),
>    indicating that only the initial hash value should be placed into a
>    DNS zone's NSEC3 records.

and be done with it. Section 3.1 repeats the same thing, so no need to 
duplicate it and risk inconsistencies.

The only other thing worth mentioning is a nit which I don't feel 
strongly about:

> 3.2.  Recommendation for validating resolvers
>    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).

Technically RRSIG validation is needed only if the resolver treats some 
combination of parameters as insecure. If it is going to SERVFAIL for 
e.g. large iteration value anyway then there is no point in validating 
the RRSIG, I think.

Additionally I've submitted PR#6 with purely editorial nits.

Thank you for your persistence!

-- 
Petr Špaček  @  Internet Systems Consortium

---

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

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

> It seems odd to have "2. Recommendation for zone publishers" followed
> by "3.1 Best-practice for zone publishers".

You bring up a good point.    When looking at it though, 3.1 really does
look written for zone publishers but actually maybe we should change the
title of 2 is actually what's wrong.  How about "NSEC3 parameter value
considerations":

   2.  NSEC3 parameter value considerations  . . . . . . . . . . . .   3
     2.1.  Algorithms  . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Flags . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Iterations  . . . . . . . . . . . . . . . . . . . . . . .   4
     2.4.  Salt  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Recommendations for deploying and validating NSEC3 records  .   5
     3.1.  Best-practice for zone publishers . . . . . . . . . . . .   6
     3.2.  Recommendation for validating resolvers . . . . . . . . .   6
     3.3.  Recommendation for Primary / Secondary relationships  . .   7

> sections 2.3. Iterations and section 3.1. Best-practice for zone

Good catch; I took your suggestion about dropping that half-sentence.

> Technically RRSIG validation is needed only if the resolver treats
> some combination of parameters as insecure. If it is going to SERVFAIL
> for e.g. large iteration value anyway then there is no point in
> validating the RRSIG, I think.

I think the reason is the error is different (eg EDE).  You're right
that the processing may be an overload (but if it is, you can always
just drop it per the other thread too).  Anyway, if others support this
change we can discuss it further, but it's been discussed before.  So to
the others: please chime in if you agree and we want to revert the
existing consensus based on this new thinking.

> Additionally I've submitted PR#6 with purely editorial nits.

Thank you!
-- 
Wes Hardaker
USC/ISI

---

From: Petr Špaček <[email-masked]>
Date: Mon, 28 Feb 2022 15:43:59 +0100

>       3.3.  Recommendation for Primary / Secondary relationships  . .   7

Sounds good to me.

> Good catch; I took your suggestion about dropping that half-sentence.

Okay, that clarifies things. Thank you!

> existing consensus based on this new thinking.

Maybe there is an option to keep the current MUST if we add an 
additional clarification?

 >>>     since record publication (see [RFC5155] section 10.3).

And here add this as continuation of the previous sentence?

... because the invalid signature might have additional implications. 
E.g. EDE code, or insecure validation status if an implementation chose 
to treat certain range of NSEC3 iteration values as DNSSEC-insecure etc.

(modulo grammar fixes etc., of course)

I think this makes the reason clear to everyone and also makes it 
somewhat legal to ignore signature validation it IF "visible outcome" 
does not change by doing so.

What do you think?

-- 
Petr Špaček

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 28 Feb 2022 12:11:08 -0500

> does not change by doing so.

I don't understand this comment, the reason for the signature check is
that otherwise we get trivial downgrade attacks.  NSEC3 replies from
a signed zone with an invalid signature MUST be treated as "bogus".

What did you have in mind?  What does "visible outcome" mean?

-- 
    Viktor.