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

From: Peter van Dijk <[email-masked]>
Date: Thu, 21 Jan 2021 12:44:37 +0100

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.

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

---

From: Brian Dickson <[email-masked]>
Date: Thu, 21 Jan 2021 18:14:37 -0800

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

Brian

---

From: Peter van Dijk <[email-masked]>
Date: Sun, 24 Jan 2021 20:20:56 +0100

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,