Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))

Peter van Dijk <peter.van.dijk@powerdns.com> Sun, 24 January 2021 19:21 UTC

Return-Path: <peter.van.dijk@powerdns.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 A37DF3A00D9 for <dnsop@ietfa.amsl.com>; Sun, 24 Jan 2021 11:21:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.403
X-Spam-Level:
X-Spam-Status: No, score=0.403 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 fGkQ1lKMt6Lk for <dnsop@ietfa.amsl.com>; Sun, 24 Jan 2021 11:21:00 -0800 (PST)
Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 140973A00D8 for <dnsop@ietf.org>; Sun, 24 Jan 2021 11:20:59 -0800 (PST)
Received: from imap.open-xchange.com (imap.open-xchange.com [84.81.54.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPSA id AEF366A244; Sun, 24 Jan 2021 20:20:56 +0100 (CET)
Received: from plato ([84.81.54.175]) by imap.open-xchange.com with ESMTPSA id nmqPKZjIDWAUIgAA3c6Kzw (envelope-from <peter.van.dijk@powerdns.com>); Sun, 24 Jan 2021 20:20:56 +0100
Message-ID: <38e41a4754106fd7ab60ea2336cae7ce680d6774.camel@powerdns.com>
From: Peter van Dijk <peter.van.dijk@powerdns.com>
To: dnsop <dnsop@ietf.org>
Date: Sun, 24 Jan 2021 20:20:56 +0100
In-Reply-To: <CAH1iCipocwCaJq_H9No-M3+pn0hGzYGfORNJs0YjRuFoDQHz-w@mail.gmail.com>
References: <20201105.172635.572683028769863094.fujiwara@jprs.co.jp> <CE990E49-38B7-4EFD-AB7E-DFA58C96D5D9@isc.org> <20201112.183133.1534594902398859181.fujiwara@jprs.co.jp> <C5C4E8F7-C202-4453-AEA3-FBF9A66969FA@icann.org> <f99456c8064e2c52ca5d7c47420338098a34da78.camel@powerdns.com> <CAH1iCipsRhE_Jx5ohBVCxM1djvL5V4PgDnVgyxVk11mS=NbVVw@mail.gmail.com> <33d239b4c082e98c2a852e802e595bbfbb7ac8c0.camel@powerdns.com> <CAH1iCipocwCaJq_H9No-M3+pn0hGzYGfORNJs0YjRuFoDQHz-w@mail.gmail.com>
Organization: PowerDNS.COM B.V.
Content-Type: multipart/alternative; boundary="=-nQurVzgr7A3L2MzzreVR"
User-Agent: Evolution 3.30.5-1.1
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/V-lmxahEPZLTS_Dp4HDmTWaeuZQ>
Subject: Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))
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: Sun, 24 Jan 2021 19:21:02 -0000

On Thu, 2021-01-21 at 18:14 -0800, Brian Dickson wrote:
> Paul's proposal would still require the parent to produce and serve the NSRRSIG. However small a change that is, it is still a change.

Yes, a change in signers and auths.

> When compared with the alternative I proposed, my suggestion does not require changes on the parent side, only on the Registrar, and possibly the child authority server, and the validating resolver.
> (Reminder, my idea was: use a new DNSSEC algorithm to stuff either the child NS set or the parent NS set into a DNSKEY record and submit that as a new DS value via existing EPP paths for updating the DS set.)

Yes, I've also informally proposed this in the past, and Fujiwara's draft is the version with signer assistance.

> I think both are viable options, where the question of whether both are truly feasible (universally, i.e. across all TLDs) is the critical issue.
> If the answer to that question is "no", then choosing the path that does not require any TLD changes (at all) would seem (to me) to be the most promising path.

There's another perspective - if TLDs do this (where 'this' is 'whatever variant that gives us signed delegation NSsets'), then a NS owner can 'enable DoT' by publishing TLSA, without having to tell all his users 'please submit this pseudo-DNSKEY record to your TLD'. This strongly argues for "let's put the pain with a few hundred TLD operators" instead of thousands of registrars, their resellers, their clients that use APIs, their clients that use webforms that do not aid them in getting things right, their NS operators that now need to provide 200% more assistance when people change operators.

In short, moving this pain into the signers&auths (both of which come from only a handful of vendors!) actually makes a lot of sense to me. Many TLDs will be able to 'implement' CNSRRSIG (or some other variant) through the regular updates I trust they already do.


Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/