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

Petr Špaček <pspacek@isc.org> Wed, 01 June 2022 09:02 UTC

Return-Path: <pspacek@isc.org>
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 04087C13CDE2; Wed, 1 Jun 2022 02:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.005
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b=MAvYg6AL; dkim=pass (1024-bit key) header.d=isc.org header.b=EzlQZFx5
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 vDw6WXZZxh9D; Wed, 1 Jun 2022 02:02:14 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 43B88C159489; Wed, 1 Jun 2022 02:00:41 -0700 (PDT)
Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.1.12]) (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 mx.pao1.isc.org (Postfix) with ESMTPS id E977F3AB01C; Wed, 1 Jun 2022 09:00:40 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org E977F3AB01C
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.1.12
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1654074041; cv=none; b=gC1UlKiKTszxftlopne7tGZ2TJyXG9N7/x2XY+gWVdae48/zh2XhGie55Ew2B16+DPG9XeBJi5xLDgddkmiPT/jPrmRzlOLvajHooC0PakgcmANv19vQyIWBD8oQQoztW5PjeZhzCbFAe+XGEjZVQOLA5X9AyRdoYOGL7zGE+iU=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; 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; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org E977F3AB01C
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; 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 zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id D3DB39C73A2; Wed, 1 Jun 2022 09:00:40 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id A14A89C73A3; Wed, 1 Jun 2022 09:00:40 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org A14A89C73A3
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; 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 zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MuYFTP7LeQtl; Wed, 1 Jun 2022 09:00:40 +0000 (UTC)
Received: from [192.168.0.158] (ip-86-49-245-107.net.upcbroadband.cz [86.49.245.107]) by zimbrang.isc.org (Postfix) with ESMTPSA id 22C239C73A2; Wed, 1 Jun 2022 09:00:38 +0000 (UTC)
Message-ID: <b3a5ee0e-b515-1170-4d39-b8e574c8950c@isc.org>
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 <wjhns1@hardakers.net>
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> <ybl35gy295m.fsf@wd.hardakers.net>
From: Petr Špaček <pspacek@isc.org>
In-Reply-To: <ybl35gy295m.fsf@wd.hardakers.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/sTd0uM0WNXMikJONvqhnJaXVprw>
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: 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