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

Peter van Dijk <peter.van.dijk@powerdns.com> Thu, 10 December 2020 21:19 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 292F53A12A7 for <dnsop@ietfa.amsl.com>; Thu, 10 Dec 2020 13:19:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Iu-XWnG2SvrI for <dnsop@ietfa.amsl.com>; Thu, 10 Dec 2020 13:19:03 -0800 (PST)
Received: from mx3.open-xchange.com (alcatraz.open-xchange.com []) (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 804183A12A5 for <dnsop@ietf.org>; Thu, 10 Dec 2020 13:19:03 -0800 (PST)
Received: from open-xchange.com (imap.open-xchange.com []) (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 ESMTPS id E51A66A312; Thu, 10 Dec 2020 22:19:00 +0100 (CET)
Received: from plato (84-81-54-175.fixed.kpn.net []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id C46843C0185; Thu, 10 Dec 2020 22:19:00 +0100 (CET)
Message-ID: <f99456c8064e2c52ca5d7c47420338098a34da78.camel@powerdns.com>
From: Peter van Dijk <peter.van.dijk@powerdns.com>
To: dnsop <dnsop@ietf.org>
Date: Thu, 10 Dec 2020 22:19:00 +0100
In-Reply-To: <C5C4E8F7-C202-4453-AEA3-FBF9A66969FA@icann.org>
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>
Organization: PowerDNS.COM B.V.
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.5-1.1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/WsnbedpaNuK5bXI35L2wlk7e3rA>
Subject: [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: Thu, 10 Dec 2020 21:19:05 -0000

Hello Paul,

On Mon, 2020-11-30 at 15:43 +0000, Paul Hoffman wrote:
> The more I think about draft-fujiwara-dnsop-delegation-information-signer, the more I think that it is much more complex than what we are doing now in DNSSEC, and therefore undesirable.

My feelings are similar but not identical - the conversation already
shows that the glue story will be almost impossible to implement. Next
to that, I haven't figured out why we'd want to authenticate glue.
However, authenticating the delegation NSset fills an obvious gap in
various suggested answers to the dprive phase2 question (privacy
between resolvers and authoritatives).

> If the goal is "a way for a signer in a parent to sign child NS in a way that does not affect validators that have not been updated (or don't care)", a significantly easier solution would be a new RRtype (maybe called "CNSRRSIG") that closely mimics RRSIG but only allows child NS for signing. An aware signer included the CNSRRSIG in the zone, and an aware authoritative server includes in in the Authority section when serving child NS records. An aware resolver can use this, an unware resolver would treat it like any other unknown RRtype that appears in the Authority section.

This makes a ton of sense to me.

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.

> There are probably a few other diffs from the RRSIG definition in RFC 403x, but they should be minor. This might make implementation more likely to be correct for signers, servers, and resolvers.

Yes, this calls for some experiments, but I suspect the outcome will be
as you described above - which means no hurdles to incremental rollout.

(I am not even convinced this needs to be a new type, vs. reusing RRSIG
under the specific semantics you described, but a new type feels
cleaner to me.)

> Thoughts?

+1 !

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