[DNSOP] Updating RFC 7344 for cross-NS consistency

Peter Thomassen <peter@desec.io> Mon, 27 June 2022 19:39 UTC

Return-Path: <peter@desec.io>
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 4AA65C15A745 for <dnsop@ietfa.amsl.com>; Mon, 27 Jun 2022 12:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=a4a.de
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 CLRBddDeaMKN for <dnsop@ietfa.amsl.com>; Mon, 27 Jun 2022 12:39:36 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [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 ietfa.amsl.com (Postfix) with ESMTPS id E21D6C157B56 for <dnsop@ietf.org>; Mon, 27 Jun 2022 12:39:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:Subject:From:To: MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=iiOWmc71pFuu204LmOXjVDuCkM6GggzDZCqtVO2miTM=; b=Pof0gSaNEHv+Psef2dKi/BHVyo GGNaiFa2gOWn1gvNipVZcm2WWoGsF8ZT55QBmklqWJvtOEbhzhquQElevvLoVGDK1Z4DORtrqIyHB VYb75nTIRusdmrLloX8itshkeONyUbrB3GWkJ1kVarrXMmkCu8fHRrIx9iiRIpUlKjYGnVb4bNavc jUFJZrHcFB8k/mpAbbO6CSLFk+XL+ARstm/OBDi6EJjJcaLafB91bJEcObTe9RNQcOxpxgey3f5mP RhUrGlA3Y0GH+GaBKNWru/N5kVD0Vjb+7gWGAua2AHg/Ht1J3Dph2HeymIbjoo0v8XXDb7CDm290v 63/xms5w==;
Received: from p200300d46f3bc9dfe5eb0045e446552f.dip0.t-ipconnect.de ([2003:d4:6f3b:c9df:e5eb:45:e446:552f]) by mail.a4a.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <peter@desec.io>) id 1o5ua7-0005oJ-27 for dnsop@ietf.org; Mon, 27 Jun 2022 21:39:35 +0200
Message-ID: <f945a354-77d7-55b8-a2c1-11c8794ae653@desec.io>
Date: Mon, 27 Jun 2022 21:39:34 +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: "dnsop@ietf.org WG" <dnsop@ietf.org>
From: Peter Thomassen <peter@desec.io>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nQQsixIT5cXFukBq4Ky67mCniAk>
Subject: [DNSOP] Updating RFC 7344 for cross-NS consistency
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, 27 Jun 2022 19:39:41 -0000

Dear DNSOP,

RFC 7344 describes DS rollovers using CDS/CDNSKEY records. It does not prescribe how the CDS/CDNSKEY records should be retrieved. On the contrary, it is fully left open (Section 6.1):

    How the Parental Agent gets the CDS/CDNSKEY RRset may differ.  Below
    are two examples of how this can take place.

This poses a problem in conjunction with multi-signer setups, which may be gaining traction (RFC 8901, draft-ietf-dnsop-dnssec-automation).


The problem is: when the CDS/CDNSKEY are retrieved "normally" using a validating resolver (and then checked as required in Section 4.1), chances are that records are retrieved from one nameserver only (that is, without checking for consistency across other NS hostnames).

In a multi-signer setup, this means that a single provider can (accidentally or maliciously) roll the DS record at the parent. IMO the most likely scenario would be that a provider performs a key rollover and then accidentally publishes CDS/CDNSKEY records for its own keys. As a result, the other providers' DS records would be removed from the parent, breaking the zone for some or all queries.


Regardless of whether that's likely to happen or not: a single provider should not be in the position to remove the other providers' trust anchors. It is therefore necessary to either

(1) require the parent to make sure that other provider's DS records remain available (but there is no reliable way of ascribing them, especially for pre-published standby DS records); or

(2) require providers to agree on what are the proper CDS/CDNSKEY record sets, so that any error by a single party is effectively vetoed.

I thus propose to update RFC 7344 along the lines of (2), such that it is REQUIRED to retrieve CDS/CDNSKEY records using queries to all authoritative nameservers.

Such a change would also prevent CDS/CDNSKEY loops, where one secondary has a replication issue and keeps announcing an old C* RRset (and the parent happens to retrieve alternating information during daily scans, for example).

Does the WG think this is a reasonable thing to pursue?

Thoughts welcome.

Best,
Peter

-- 
https://desec.io/