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

Petr Špaček <> Wed, 01 June 2022 09:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 04087C13CDE2; Wed, 1 Jun 2022 02:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.005
X-Spam-Status: No, score=-4.005 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.876, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=MAvYg6AL; dkim=pass (1024-bit key) header.b=EzlQZFx5
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vDw6WXZZxh9D; Wed, 1 Jun 2022 02:02:14 -0700 (PDT)
Received: from ( []) (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 (Postfix) with ESMTPS id 43B88C159489; Wed, 1 Jun 2022 02:00:41 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by (Postfix) with ESMTPS id E977F3AB01C; Wed, 1 Jun 2022 09:00:40 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 E977F3AB01C
Authentication-Results:; arc=none smtp.remote-ip=
ARC-Seal: i=1; a=rsa-sha256;; s=ostpay; t=1654074041; cv=none; b=gC1UlKiKTszxftlopne7tGZ2TJyXG9N7/x2XY+gWVdae48/zh2XhGie55Ew2B16+DPG9XeBJi5xLDgddkmiPT/jPrmRzlOLvajHooC0PakgcmANv19vQyIWBD8oQQoztW5PjeZhzCbFAe+XGEjZVQOLA5X9AyRdoYOGL7zGE+iU=
ARC-Message-Signature: i=1; a=rsa-sha256;; s=ostpay; t=1654074041; c=relaxed/relaxed; bh=pkAd6eUSN1V06fv0pD26a9BCWIjQdfyCul/863KXldc=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=W1R0Vu+ZzkiZ08iWwier4zg7vYy2zLVe7P/S4tM9vFnE3BJ/yvNANfADnQoYmc2DI7D4XuG4ymbbZWILnD0tPG+Ju9nGUVTt+V6ltj8ALE8IxoInNNyG6MlpMLg0b4gZ2hBr9m61KqK+t1DXpJZMkX2tw6dZvKsVcQokthTV89M=
ARC-Authentication-Results: i=1;
DKIM-Filter: OpenDKIM Filter v2.10.3 E977F3AB01C
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=ostpay; t=1654074041; bh=KFYGPLGaspgzko+Kjn5ZkbyFGehoMz6RXBTQMLs6npI=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=MAvYg6ALvcUdU555SE/mFvknOpPsbqmCV/4v1tzPdNOF+tw6S7NsCc7MiqDMTPxT1 4c42OAARPRXKIbOrFkvtX/hF4aWgusIQvvqk5BMB7tPWKB4I6MIpDfMHcwi+6+pgvR VbzKMSlA+wzrBOWAVI7T+JeL276q5jc2psqRM7rU=
Received: from (localhost.localdomain []) by (Postfix) with ESMTPS id D3DB39C73A2; Wed, 1 Jun 2022 09:00:40 +0000 (UTC)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id A14A89C73A3; Wed, 1 Jun 2022 09:00:40 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 A14A89C73A3
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1654074040; bh=pkAd6eUSN1V06fv0pD26a9BCWIjQdfyCul/863KXldc=; h=Message-ID:Date:MIME-Version:To:From; b=EzlQZFx5+GeteGXlfSM27NRrcP0CoZ/GPKjAqsfFIw4wDiBpuUb73nqOR9uF3RaGC AcSDk412IXJ8VbVA+e4FmKYuiAkHVcMHmLPp9/4KT3MQhSUjWt0y7kGUHWJ6w8X6w7 wZ1HhLZ7GgswL8o80yyCgxn6YZKcqpQShY2swjcY=
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id MuYFTP7LeQtl; Wed, 1 Jun 2022 09:00:40 +0000 (UTC)
Received: from [] ( []) by (Postfix) with ESMTPSA id 22C239C73A2; Wed, 1 Jun 2022 09:00:38 +0000 (UTC)
Message-ID: <>
Date: Wed, 01 Jun 2022 11:00:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-US
To: Wes Hardaker <>
Cc: The IESG <>, Roman Danyliw <>,,,,
References: <> <>
From: Petr Špaček <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Jun 2022 09:02:18 -0000

On 24. 05. 22 18:21, Wes Hardaker wrote:
>> ** 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.

Sorry for being so late on this ...

I think we cannot really do better than "large" because definition of 
"large" changes every year with new a new CPU model or software 
optimization (e.g. better parallelization).

For that reason I believe Wes's proposal is a good one, albeit very generic.

Petr Špaček