Re: [DNSOP] nsec3-parameters opinions gathered

Vladimír Čunát <vladimir.cunat+ietf@nic.cz> Fri, 05 November 2021 08:40 UTC

Return-Path: <vladimir.cunat+ietf@nic.cz>
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 2FEB23A0DAE for <dnsop@ietfa.amsl.com>; Fri, 5 Nov 2021 01:40:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.43
X-Spam-Level:
X-Spam-Status: No, score=-5.43 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=-3.33, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 Hu-wpfnwNZ9z for <dnsop@ietfa.amsl.com>; Fri, 5 Nov 2021 01:40:09 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 57EC33A0DAB for <dnsop@ietf.org>; Fri, 5 Nov 2021 01:40:08 -0700 (PDT)
Received: from [IPV6:2001:1488:fffe:6:35ef:325b:7b47:a0ab] (unknown [IPv6:2001:1488:fffe:6:35ef:325b:7b47:a0ab]) by mail.nic.cz (Postfix) with ESMTPSA id B7A721407BF for <dnsop@ietf.org>; Fri, 5 Nov 2021 09:40:04 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1636101604; bh=39lOpR6RxAww/1PbNIwv8Cl9p3OED/5zrrwXInqwTqg=; h=Date:To:From; b=bC0dOFhWoLcai6e5zWP+M9imfnMC+dZ7Nwli+I4oHV1VO72M7Gtk0xWb+2zPlHqXt YItOccQG4uwoIDK1113v6BTfsTu8W+oz5V7knKO/Xi56HMKUKipAt8GGvYuzZYHrK/ h8Zck+hOZHYb21JZSD96E3zyoiJ6qqgmV0CA1LBU=
Message-ID: <206e17b4-a920-8e3e-586d-ecc29855fae3@nic.cz>
Date: Fri, 05 Nov 2021 09:40:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1
Content-Language: en-US
To: dnsop@ietf.org
References: <ybl7ddnr16f.fsf@w7.hardakers.net>
From: Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
In-Reply-To: <ybl7ddnr16f.fsf@w7.hardakers.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.102.4 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/v0-mFn2vWLLew7tI0PM28I93HH4>
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: Fri, 05 Nov 2021 08:40:14 -0000

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.

I'm not sure how low a "SERVFAIL limit" could go, though.  (And I 
probably won't bring other stuff like salt into this thread.)

--Vladimir