Re: [DNSOP] nsec3-parameters opinions gathered

Matthijs Mekking <matthijs@pletterpet.nl> Mon, 08 November 2021 08:34 UTC

Return-Path: <matthijs@pletterpet.nl>
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 AD3E23A0B58 for <dnsop@ietfa.amsl.com>; Mon, 8 Nov 2021 00:34:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.248
X-Spam-Level:
X-Spam-Status: No, score=-5.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-3.33, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 92VjNNJsMSuE for <dnsop@ietfa.amsl.com>; Mon, 8 Nov 2021 00:34:31 -0800 (PST)
Received: from lb2-smtp-cloud7.xs4all.net (lb2-smtp-cloud7.xs4all.net [194.109.24.28]) (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 535443A0B19 for <dnsop@ietf.org>; Mon, 8 Nov 2021 00:34:30 -0800 (PST)
Received: from cust-69fe625f ([IPv6:fc0c:c103:c4a6:cf3c:d2f9:56fe:3f93:cb0b]) by smtp-cloud7.xs4all.net with ESMTPSA id k06hmeNCjFZvck06jmuChm; Mon, 08 Nov 2021 09:34:28 +0100
To: dnsop@ietf.org
References: <ybl7ddnr16f.fsf@w7.hardakers.net> <206e17b4-a920-8e3e-586d-ecc29855fae3@nic.cz> <45a10ca4-93e1-3c9c-7434-83c387d5246e@NLnetLabs.nl>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <4254eece-a024-dbe4-3a64-a7ff957ce945@pletterpet.nl>
Date: Mon, 08 Nov 2021 09:34:23 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <45a10ca4-93e1-3c9c-7434-83c387d5246e@NLnetLabs.nl>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4xfPghuwjZR3Wl7o71oHJR8ygUK3nLMlcEwUM7aP0Rmz3CyL9LCe91X0vZPG61IBHjaYMA8GmIi60G1P0Sf0dvPvCdtN21sYuWi+3SQCGFfjvFtkgQuC6X 3YUI1RRyJ2My3SziOTSHEFADdGg2BK1gmBKD1vlegmF1dmClY00sYDVOzIKwY4GRzRMj8KFKScVoJ2Xon6tnppG9i3zCvcbZbFsWLDTVeY0J6hTOooRz3iCG btjuAiGR45+Kg2qrzjUK/U8viv+sV7qhb+YRxCcHc7drlFLiO+LAPtoSpS6X6aDt
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3QVRa7Zrzzf2Z-2dQrnd-hKySkg>
Subject: Re: [DNSOP] nsec3-parameters opinions gathered
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: Mon, 08 Nov 2021 08:34:34 -0000

I concur with Benno.

For Bind 9, there is no technical challenge to set the iteration cap at
a lower value.

We prefer the value to be as low as possible, because it adds no real
value at a real resource cost.

But we will likely not implement blindly a maximum that will cause lots
of operational problems.

Best regards,

Matthijs

On 11/5/21 5:09 PM, Benno Overeinder wrote:
> Wes,
> 
> On 05/11/2021 09:40, Vladimír Čunát wrote:
>> On 04/11/2021 23.44, Wes Hardaker wrote:
>>> The most important sticking point is there are 4 implementations (thank
>>> you for the links Matthijs) that have implemented 150.  Since DNSOP
>>> strives for implementations of specs, I think this is the number we
>>> should publish*unless the vendors speak up and say they'll drive lower*.
>>
>> I'm convinced that 150 was just a quick stop-gap compromise and that
>> from the start vendors expected that dnsop might set it lower later.
>> Therefore I don't think this *argument* for keeping 150 is really valid.
>>
>> As for Knot Resolver, I see no problem in setting the hard limit
>> lower, especially if that gets published in this RFC.  From Viktor I
>> gather that 100 shouldn't cause issues even at this moment, especially
>> if it's only a limit for downgrading to insecure (which won't be even
>> noticed by most DNS consumers).  So personally I expected the draft to
>> lower the bound to <=100, though as I said... for us the *overall*
>> performance ratio from e.g. 150 -> 50 isn't that large.
> 
> For Unbound, we have no problem setting the iteration cap to a value
> lower than the current 150.  If Viktor's analysis shows a limit of 100
> is feasible without (m)any problems for operators, and this value will
> be adopted in the soon-to-be-released RFC, we will use the new limit value.
> 
> 
> Cheers,
> 
> -- Benno
> 
>