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

Wes Hardaker <wjhns1@hardakers.net> Fri, 25 February 2022 23:40 UTC

Return-Path: <wjhns1@hardakers.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B569C3A0AFE for <dnsop@ietfa.amsl.com>; Fri, 25 Feb 2022 15:40:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zvYuq5_q4j0 for <dnsop@ietfa.amsl.com>; Fri, 25 Feb 2022 15:40:22 -0800 (PST)
Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208D83A08CC for <dnsop@ietf.org>; Fri, 25 Feb 2022 15:40:22 -0800 (PST)
Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 6842B246D5; Fri, 25 Feb 2022 15:40:21 -0800 (PST)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Petr Špaček <pspacek@isc.org>
Cc: dnsop@ietf.org, Wes Hardaker <ietf@hardakers.net>, Viktor Dukhovni <ietf-dane@dukhovni.org>
References: <164444559960.6598.511176363502657811@ietfa.amsl.com> <ybltud77k01.fsf@w7.hardakers.net> <bf796286-74ac-78de-226c-a050dcf751b7@isc.org>
Date: Fri, 25 Feb 2022 15:40:21 -0800
In-Reply-To: <bf796286-74ac-78de-226c-a050dcf751b7@isc.org> ("Petr Špaček"'s message of "Thu, 10 Feb 2022 12:59:15 +0100")
Message-ID: <ybl35k6347u.fsf@w7.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/aiNZ-DumrmGo05iLcS3One1vnNE>
Subject: Re: [DNSOP] New Version Notification for draft-ietf-dnsop-nsec3-guidance-03.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Feb 2022 23:40:27 -0000

Petr Špaček <pspacek@isc.org> writes:

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

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


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

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

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

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