Re: [DNSOP] [Ext] About key tags

Philip Homburg <pch-dnsop-5@u-1.phicoh.com> Mon, 04 March 2024 08:29 UTC

Return-Path: <pch-b538D2F77@u-1.phicoh.com>
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 3EA54C14F721 for <dnsop@ietfa.amsl.com>; Mon, 4 Mar 2024 00:29:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 ShnK4_jn5uJp for <dnsop@ietfa.amsl.com>; Mon, 4 Mar 2024 00:29:00 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [45.83.6.19]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 415FFC14F6A0 for <dnsop@ietf.org>; Mon, 4 Mar 2024 00:28:56 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #158) id m1rh3gl-0000KqC; Mon, 4 Mar 2024 09:28:47 +0100
Message-Id: <m1rh3gl-0000KqC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
Cc: Peter Thomassen <peter@desec.io>
From: Philip Homburg <pch-dnsop-5@u-1.phicoh.com>
Sender: pch-b538D2F77@u-1.phicoh.com
References: <BBA3FCAF-C5AA-40B0-A1E7-6773330A8E30@fl1ger.de> <FB36282B-5C87-4ED0-8669-D0438666F08D@strandkip.nl> <CANLjSvUi31srBhcUP513egeiKHGfMRyyRZrqYwLHug_n_i=K2A@mail.gmail.com> <D36D404C-C495-4838-BECA-417801327282@icann.org> <m1rg5V1-0000M5C@stereo.hq.phicoh.net> <5B66188E-0615-45C4-BAD3-F546F7F88254@icann.org> <m1rg7sM-0000LXC@stereo.hq.phicoh.net> <fbdb9145-4f98-469d-a8cb-b0a5dedd0ca2@desec.io>
In-reply-to: Your message of "Sat, 2 Mar 2024 16:55:59 -0400 ." <fbdb9145-4f98-469d-a8cb-b0a5dedd0ca2@desec.io>
Date: Mon, 04 Mar 2024 09:28:47 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/YYNM1NWi-s_u0sQMu74L3_wB7LE>
Subject: Re: [DNSOP] [Ext] About key tags
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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, 04 Mar 2024 08:29:02 -0000

In your letter dated Sat, 2 Mar 2024 16:55:59 -0400 you wrote:
>The core DNSSEC protocol includes multi-signer. RFC 8901 just spells out expli
>citly how it is covered by the protocol; that's why its status is Informationa
>l.
>
>> The first step to conclude is that for the core DNSSEC protocol, requiring
>> unique key tags is doable.
>
>No. There is no core and non-core part of the spec. Support for multiple keys,
> including keytag collisions, simply is part of that protocol.

What I mean is that if we take all of the standards track DNSSEC RFCs and we
add a new RFC that says something to the effect:
1) A signer MUST NOT sign a DS or DNSKEY RRset if the set has duplicate key
   tags.
2) An authoritative DNS server MUST not serve a set of RRSIG records that 
   corresponds to a single RRset where the collection of RRSIG records has a
   duplicate key tag.

then as far as I can tell, there is no conflict with currently published
standards track DNSSEC RFCs. 

In addition for most signers and authoritative servers it will be easy to meet
those requirements and many signers are already in line with those 
requirements.

The only thing that prevents us from publishing such an update is an
informational RFC about multi-signers (or other practices that are not
documented or standardized within the IETF).