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

Peter Thomassen <peter@desec.io> Tue, 28 June 2022 13:52 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 F0FF0C15A75E for <dnsop@ietfa.amsl.com>; Tue, 28 Jun 2022 06:52:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.782
X-Spam-Level:
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_DNSWL_BLOCKED=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: 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 muCh5Qyi80jP for <dnsop@ietfa.amsl.com>; Tue, 28 Jun 2022 06:52:30 -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 6F16FC15A72F for <dnsop@ietf.org>; Tue, 28 Jun 2022 06:52:30 -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: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=/A3TtbzXD2V2EMvKHJHoplSFnhv9pSg8vIV0L1HySPs=; b=ABHBO9rIegykp8jDDbMENoJ8Ls /H2sG/iTprufv+WctpT2VGVIcP7RBDmn1FR2iXj9Oj8pzle4AoOgODQfhFlzCAdBFGsiAWoKOA5FB e8v7wel+zNUsUUj/e85D/W12EOZ/i2TPLT/98Nehlfv3RGpiqRdhki47CJ4llJsn7xLFP5sT2eEwL SpGzBvN/49MfSJA2U2IU/kO70vm86eP3IqZolfYApGHfski3fFWowG097a7oz2Ub989nJFKJLlp9H LGproavEtLv5Tz6QAP0NymuAp9xVLc02wkV5EpA01RelhXUE5H/49uAC6B//f8sK/BiXPVvRfT8vL IoJoYP9g==;
Received: from p200300d46f11ea05aa90bbd3c23e9a87.dip0.t-ipconnect.de ([2003:d4:6f11:ea05:aa90:bbd3:c23e:9a87]) 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 1o6Bdj-0002X4-Fz; Tue, 28 Jun 2022 15:52:27 +0200
Message-ID: <0e230058-080a-dd30-8808-f66eb9a1dc47@desec.io>
Date: Tue, 28 Jun 2022 15:52:25 +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 <paul@nohats.ca>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
References: <f945a354-77d7-55b8-a2c1-11c8794ae653@desec.io> <9cc0c19f-da83-72ae-a940-16f1662bf29@nohats.ca>
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <9cc0c19f-da83-72ae-a940-16f1662bf29@nohats.ca>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BFO4-GDXIWzQsQJKCyZcTX9r-U0>
Subject: Re: [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: Tue, 28 Jun 2022 13:52:35 -0000


On 6/28/22 02:56, Paul Wouters wrote:
>> 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.
> 
> The question is now how to phrase this exactly. Do we want the parent to use
> its "external" knowledge of NS records of the child - eg from its WHOIS data?
> That would be clean and simple.
> 
> Or are we okay that it queries for the NS records to get the list ?
> If so, it would need to require DNSSEC for the NS RRset, but there might
> be more than one validly signed NS RRset if these nameservers are out
> of sync. In that case, which of these is the intended one?

The parental agent has unerring knowledge of the delegation NS records, so I think those should be used. This is also what's done for bootstrapping, where the child-side NS RRset is not yet trusted.

For the reason you mentioned and for consistency with bootstrapping, I'd suggest to choose phrasing that similar to that in the bootstrapping draft, such as (inspired by in draft-ietf-dnsop-dnssec-bootstrapping, Section 3.2):

    Query the CDS/CDNSKEY records at the Child zone apex directlyfrom
    each of the authoritative servers as determined by thedelegation's
    NS record set using a trusted DNSresolver and enforce DNSSEC
    validation

or (inspired by bootstrapping Section 3.3):

    The Parental Agent MUST ascertain that queries are only made against
    the proper set of nameservers as listed in the Child's delegation
    from the Parent.

Having this aligned allows CDS/CDNSKEY scanners to use the same query logic for bootstrapping and for rollovers.

>> Does the WG think this is a reasonable thing to pursue?
> 
> I think this could be an excellent super short RFC that Updates: 7344.

Sure, I'm volunteering to write up something. I'll wait until Thursday or so, in case others share thoughts I should know before I start.

Thanks,
Peter

-- 
https://desec.io/