Re: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)

Wes Hardaker <wjhns1@hardakers.net> Tue, 24 May 2022 16:22 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 88598C139540; Tue, 24 May 2022 09:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drQpQAsEhPvQ; Tue, 24 May 2022 09:21:58 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B4DC15E41E; Tue, 24 May 2022 09:21:58 -0700 (PDT)
Received: from localhost (unknown [10.0.0.9]) by mail.hardakers.net (Postfix) with ESMTPA id B173B20686; Tue, 24 May 2022 09:21:57 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Roman Danyliw via Datatracker <noreply@ietf.org>
Cc: "The IESG" <iesg@ietf.org>, Roman Danyliw <rdd@cert.org>, draft-ietf-dnsop-nsec3-guidance@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, tjw.ietf@gmail.com
References: <165220750351.60909.14025124030421009706@ietfa.amsl.com>
Date: Tue, 24 May 2022 09:21:57 -0700
In-Reply-To: <165220750351.60909.14025124030421009706@ietfa.amsl.com> (Roman Danyliw via Datatracker's message of "Tue, 10 May 2022 11:31:43 -0700")
Message-ID: <ybl35gy295m.fsf@wd.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/EPdqdZ5fT2PqzpDgkVHUkhjMkI0>
Subject: Re: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.34
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: Tue, 24 May 2022 16:22:00 -0000

Roman Danyliw via Datatracker <noreply@ietf.org> writes:

> ** I support Paul Wouter’s DISCUSS position.  Like Alvaro and Francesca also
> commented, this document appears to be changing the behavior of RFC5155.  It
> should formally update it in the meta data.  Specifically:

As discussed in other threads, the next version will be marked as
updating RFC5115.

> ** Section 2.
>    The following sections describe recommendations for setting
>    parameters for NSEC3 and NSEC3PARAM.
> 
> I don’t believe this is accurate.  There are few tangible recommendations about
> iterations or salts in this section.  That’s in Section 3.

How's this instead:

    The following sections describes the background of the parameters for
    the NSEC3 and NSEC3PARAM resource record types.


> ** Section 2.2.
>    In general, NSEC3 with the Opt-Out flag enabled
>    should only be used in large, highly dynamic zones with a small
>    percentage of signed delegations.  Operationally, this allows for
>    fewer signature creations when new delegations are inserted into a
>    zone.  This is typically only necessary for extremely large
>    registration points providing zone updates faster than real-time
>    signing allows or when using memory-constrained hardware
> 
> Qualitative scales such as “large … dynamic zones” and “extremely large
> registration points” used.  Can the operational experience informing these
> statements be cited to suggest the scale?

That's both a fair point but hard to fix.  In early versions of this
document, we used more strict wording in places (but not for this
case).  But in the end we're trying to address a sliding problem, and
there is no perfect line to be drawn.

How about if we end the paragraph with this:

    Operators considering the use of NSEC3 are advised to fully test
    their zones deployment architectures and authoritative servers under
    both regular operational loads to determine the tradeoffs using
    NSEC3 instead of NSEC.

> ** Section 3.1.
>    Operators are encouraged to forgo using a salt entirely by using a
>    zero-length salt value instead (represented as a "-" in the
>    presentation format).
> 
> Section 2.4 seemed to take a stronger position on the lack of utility of the
> salt.  Is there a reason normative language isn’t being used?

Good point.  I've changed it to this:

    Operators SHOULD NOT use a salt by indicating a zero-length salt value
    instead (represented as a "-" in the presentation format).

-- 
Wes Hardaker
USC/ISI