[DNSOP] draft-hoffman-dnssec-iana-cons

Vladimír Čunát <vladimir.cunat+ietf@nic.cz> Tue, 17 November 2020 08:10 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 9AC9C3A0418 for <dnsop@ietfa.amsl.com>; Tue, 17 Nov 2020 00:10:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 qjdFYWOnj9Bo for <dnsop@ietfa.amsl.com>; Tue, 17 Nov 2020 00:10:02 -0800 (PST)
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 F08293A03FC for <dnsop@ietf.org>; Tue, 17 Nov 2020 00:10:01 -0800 (PST)
Received: from [IPv6:2a02:768:2d1c:226::a2e] (unknown [IPv6:2a02:768:2d1c:226::a2e]) by mail.nic.cz (Postfix) with ESMTPSA id 122AA13FDE6 for <dnsop@ietf.org>; Tue, 17 Nov 2020 09:09:59 +0100 (CET)
From: Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
To: dnsop@ietf.org
Message-ID: <52b356d0-28aa-2b5c-c1d1-3178c50beb51@nic.cz>
Date: Tue, 17 Nov 2020 09:09:58 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BifBI-6aDPaj3is2rigUh0TTsPU>
Subject: [DNSOP] draft-hoffman-dnssec-iana-cons
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: Tue, 17 Nov 2020 08:10:04 -0000

Hello.

I didn't speak but I'd still like to indicate my support.  Requiring
"Standards Action" just to allocate algorithm numbers seems quite an
overkill.  I'd find it healthy to split that into an easier step, so
it's also clearly separable from endorsing or even requiring support for
those algorithms (documents like RFC 8624).

Behavior with unsupported algorithms isn't ideal but it's specified and
seems OK to me.  People signing with less supported algorithms will
naturally be put at a disadvantage, but they do know the tradeoff
beforehand.  And... without allocated numbers you don't really want to
deploy the algorithm in validators, so it's a bit chicken-egg situation.

--Vladimir | Knot Resolver dev.