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

Brian Dickson <> Fri, 22 January 2021 02:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B46323A0FBB for <>; Thu, 21 Jan 2021 18:14:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 9X2MJ0PQF_mY for <>; Thu, 21 Jan 2021 18:14:48 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD8123A0FB2 for <>; Thu, 21 Jan 2021 18:14:48 -0800 (PST)
Received: by with SMTP id j138so1903594vsd.8 for <>; Thu, 21 Jan 2021 18:14:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P59aBaOnS9f3vYOLbeQauKc/Gayx9FgqDXHg4Ciahlo=; b=ktaiM3/Nx8pjAS0A+o1P8Ou44i05XHK8kQ99z573ndS0wjW/W4x+jhyHhzRPIse3Ut MMQrb4r4AES7TIH7Y3abQNkTvph7A5CPKdcwkOGyUzsssR/wELFxhluyMoUg6Tn4/AWT 63Xgcqa50x4/yvIkqjwj12kkSigqFz6tJ6jsroqXSxUlBdOO/KNInVyNgDkHRfFgd1NU tTHN9RFiubFAaIDq3E7aQTNA/OBLfqPihd06uSFBmMZzQAlhrgD41UFOwkSw2lwlmfM+ vaCX1auKx9TG5fztsvD8fC6oi0jAytlR5ZcTMuOTttInXIJV/5J9rQs1ZaMffjwGUuMv bbeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=P59aBaOnS9f3vYOLbeQauKc/Gayx9FgqDXHg4Ciahlo=; b=rpVfi+jbbNvBacat2T7WTpZ8FEq8ZKzGTnf+kYA+RIWnUCXcbEyW8dcWRzDmKtPmtw INwMdfoJKJJyHdArJd7j3RqtkZMl+q9pFAB9nlcL2EzO987tkDVCNnPRkROoBmOyE2h/ jojONqIfaIC94ZRUHOyLGxRhHAPqodcqrUYrkk1pe+ZiGPMBErrK26u6xpA8h6NgzXkr 5zORTrDxDyXcpmoxVXCw04HgnRUQw6fTkGd8D92qpHlqEsoZXf4Hjx7M3ZlLRAt8IkdL 4Ug+9IpPWczwG06yfPVf0FpVN8sns5ZViVd8CFtLA8x3ZggxGaDn7zSznqT3clI3Qp5E JMqw==
X-Gm-Message-State: AOAM5323P3S2IuyqnjV5Bqp/yFrbToe7Aonilz1jPlD4NRZbkizJXzwv 64jdzmjCRU+Y7SV//lT0M/DrB/2j+LXWL3OZ/acfEuDW
X-Google-Smtp-Source: ABdhPJyG+ZT+DE8Dst3JuEw0Zdaqr9Gwsy3T/a+7NWbCfGD3kaMckvGxdFUFGCJgDgjchRw/C3IfLFZ73CLjvaTFR4U=
X-Received: by 2002:a67:d786:: with SMTP id q6mr1574218vsj.1.1611281687700; Thu, 21 Jan 2021 18:14:47 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Thu, 21 Jan 2021 18:14:37 -0800
Message-ID: <>
To: Peter van Dijk <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="000000000000a0e87b05b973c086"
Archived-At: <>
Subject: Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Jan 2021 02:14:51 -0000

On Thu, Jan 21, 2021 at 3:45 AM Peter van Dijk <>

> On Thu, 2020-12-10 at 15:48 -0800, Brian Dickson wrote:
> > >
> > > Compared to DiS, registrar complexity is identical (because the
> > > complexity is also hidden in the signer here); signer complexity is
> > > potentially lower. The only real complexity change vs. DiS is in the
> > > auths, that now need to know to serve CNSRRSIG from the parent side in
> > > the additional part of a delegation response. For resolvers, this vs.
> > > DiS is again pretty much moot.
> >
> > The CNSRRSIG would also require delegation auths (i.e. TLDs) to make
> changes
> That is what the quoted text means to convey, sorry if that was
> unclear!
> > , and I think also require EPP changes.
> I don't see how EPP comes into it at all. The signer signs all NSsets;
> the auth serves the signatures with the delegations; done.

My understanding of Paul's idea is that "CNSRRSIG" is RRSIG(child's (apex)
NS set), which could be different from the delegation NS set.
IFF that is what it is, then the parent would need that information (what
the child NS set is), which would require some change, either on the parent
(TLD) side to poll for that, or on the Registrar side to submit it (via
My strong suspicion is the EPP path would have less resistance.
OTOH, if CNSRRSIG is really NSRRSIG, i.e. RRSIG(delegation NS set), then
there is no requirement for any EPP stuff (or for the TLD to poll for the
child NS set).

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.

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.)

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.