Re: [DNSOP] Updating RFC 7344 for cross-NS consistency

Peter Thomassen <> Wed, 29 June 2022 16:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D0F78C14F73F for <>; Wed, 29 Jun 2022 09:28:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.782
X-Spam-Status: No, score=-3.782 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-1.876, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wyO6pncNxIPe for <>; Wed, 29 Jun 2022 09:28:36 -0700 (PDT)
Received: from ( [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B6896C14F73E for <>; Wed, 29 Jun 2022 09:28:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:Subject:From :References:Cc:To:MIME-Version:Date:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=5kYnzhJrlD8oPCyq7O+De8q9RGgLAuH5hkG/HkYvnoA=; b=lZFM8IcrTlO8eqhhIgKVc7VfZP Q3/tmkqsrhATiR0ihNzsAIzikH/6kmIAmCoy2kbfIuGrrfLUrg5ouQHAhIT8N9ePmbwAa2Q7dmxtU sXiHd65zBZRforToxo6+wtX3mmtpWoSV3wZyK9WZUBC8NhzX/jVpeq3e6oMfGULWD9eSPgkUuNsat jAxz9M8s0NHdBYVV0RBZ8elzqYV9nFGSTctNw3IaeU7x1fxat4VL17FroIZzmFyKuMb+0DgT92cCE 0tg+PVDHDFVQ53OJGN4/JZJBfHD5C9/nLjU5S/UKKKYolf2rsB7H2PkcrAXl13MUJ3Zm4teW1aItv Vcrod0bg==;
Received: from [2a00:20:604f:8c1c:94b0:407d:667f:8c9] by with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <>) id 1o6aYK-0001Bg-Sh; Wed, 29 Jun 2022 18:28:33 +0200
Message-ID: <>
Date: Wed, 29 Jun 2022 18:28:32 +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: Paul Wouters <>
Cc: " WG" <>
References: <> <>
From: Peter Thomassen <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] Updating RFC 7344 for cross-NS consistency
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Jun 2022 16:28:41 -0000

On 6/28/22 02:56, Paul Wouters wrote:
>> Does the WG think this is a reasonable thing to pursue?
> I think this could be an excellent super short RFC that Updates: 7344.
Reading RFC 7344 more closely, I stumbled upon this paragraph in Section 4.1:

    o  Signer: MUST be signed with a key that is represented in both the
       current DNSKEY and DS RRsets, unless the Parent uses the CDS or
       CDNSKEY RRset for initial enrollment; in that case, the Parent
       validates the CDS/CDNSKEY through some other means (see
       Section 6.1 and the Security Considerations).

This is commonly taken to mean that "Like DNSKEY records, CDNSKEY and CDS records must be signed by the zone’s KSK" (

However, strictly speaking: the above provision allows that the key that signs CDS/CDNSKEY records is in the DNSKEY rrset, and referenced by a DS record, but does *not* sign the DNSKEY (i.e. is not a KSK).

This is legal iff the zone has (another) KSK of the same algorithm that is also referenced in a DS record (see last paragraph of RFC 4035 Section 2.2).

The situation would amount to pre-publishing a spare KSK in DNSKEY and DS without using it for signing; then, begin its use inside the zone with an RRSIG over CDS/CDNSKEY. But when making the key available for signing CDS/CDNSKEY, it could also sign DNSKEY, turning it into a full-fledged KSK. -- It's not clear to me what could be the motivation for this edge case, where the CDS/CDNSKEY signing key has a corresponding DS record, but does not sign DNSKEYs.

Perhaps it is just unfortunate phrasing in RFC 7344, and the authors simply intended to say that CDS/CDNSKEY must be signed by a KSK? (And then, it would make sense if it were signed by a KSK of each algorithm!)

What do you think about these aspects? In the short update RFC, do you think they would be worth clarifying?