Re: [DNSOP] [Ext] draft-fujiwara-dnsop-delegation-information-signer

Paul Hoffman <paul.hoffman@icann.org> Mon, 30 November 2020 15:43 UTC

Return-Path: <paul.hoffman@icann.org>
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 CF7FB3A0DEF for <dnsop@ietfa.amsl.com>; Mon, 30 Nov 2020 07:43:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 t9deiAwQ87Vy for <dnsop@ietfa.amsl.com>; Mon, 30 Nov 2020 07:43:24 -0800 (PST)
Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (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 2E5893A0DA5 for <dnsop@ietf.org>; Mon, 30 Nov 2020 07:43:24 -0800 (PST)
Received: from MBX112-E2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.7]) by ppa2.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 0AUFhNEv008660 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <dnsop@ietf.org>; Mon, 30 Nov 2020 15:43:23 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.721.2; Mon, 30 Nov 2020 07:43:22 -0800
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0721.004; Mon, 30 Nov 2020 07:43:22 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: dnsop <dnsop@ietf.org>
Thread-Topic: [Ext] [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
Thread-Index: AQHWxy+I85oF7MZfHkevseDDazjOJg==
Date: Mon, 30 Nov 2020 15:43:22 +0000
Message-ID: <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>
In-Reply-To: <20201112.183133.1534594902398859181.fujiwara@jprs.co.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_34661351-DD3C-46EC-973A-C609CF39C7DF"; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-30_05:2020-11-30, 2020-11-30 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/SlZ5WBXmEy-ElPYLiht56pyv6J4>
Subject: Re: [DNSOP] [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: Mon, 30 Nov 2020 15:43:27 -0000

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.

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.

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.

Thoughts?

--Paul Hoffman