[DNSOP] CDS and multi-provider DNSSEC

Tony Finch <dot@dotat.at> Fri, 01 February 2019 12:35 UTC

Return-Path: <dot@dotat.at>
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 17451127133 for <dnsop@ietfa.amsl.com>; Fri, 1 Feb 2019 04:35:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 P2L9zZsOmYfv for <dnsop@ietfa.amsl.com>; Fri, 1 Feb 2019 04:34:59 -0800 (PST)
Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 A2818126C7E for <dnsop@ietf.org>; Fri, 1 Feb 2019 04:34:59 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:51758) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1gpY25-000uD0-eL (Exim 4.91) for dnsop@ietf.org (return-path <dot@dotat.at>); Fri, 01 Feb 2019 12:34:57 +0000
Date: Fri, 01 Feb 2019 12:34:57 +0000
From: Tony Finch <dot@dotat.at>
To: dnsop@ietf.org
Message-ID: <alpine.DEB.2.20.1902011135060.16399@grey.csi.cam.ac.uk>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/l0RJQ65IvXPm1FZbSaCWSHn_FUA>
Subject: [DNSOP] CDS and multi-provider DNSSEC
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: Fri, 01 Feb 2019 12:35:02 -0000

I'm working on tools for KSK rollover automation at the moment.

It turns out that CDS records are very useful even if your parent zone
doesn't check them.

KSK rolls work better when the DS records are not simply generated from
the current DNSKEY RRset. You need to be a bit more clever if you want to
minimize interactions with the parent zone, or minimize the DNSKEY RRset
size, or do an algorithm rollover.

So your tool for setting DS records needs some way to ask the key store
what DS records should be. The nice thing about CDS records is that they
provide a standard way to do this, independent of the key store or signing
software. This allows registrar API clients to be decoupled from the
DNSSEC implementation.

This makes me wonder how well this observation generalizes to
multi-provider DNSSEC.

In model 1, the zone owner manages the KSK, so all the CDS/DS logic
remains centralized.

In model 2, each DNS provider has its own KSK, and does its own DNSKEY
RRset management. In order to support CDS/CDNSKEY, I think it is necessary
for each provider to (somehow) generate RRsets that are the union of their
CDS/CDNSKEY RRsets and the other provider's.

In normal cases, I think the "somehow" involves getting the other
provider's RRset, replacing any records corresponding to this provider's
keys with what this provider thinks they should be, and retaining any
records for unknown keys (which presumably belong to the other provider).
There's a mildly awkward risk of zombie records that are copied back and
forth despite neither provider knowing about them, but I suppose that can
be fixed manually if it arises. Or maybe it's simpler if this is done via
an API, like ZSK sharing :-)

Algorithm rollovers are more difficult, because loose consistency will not
work: a new algorithm needs to be introduced into the DS RRset for all
providers at the same time, and same for removing an old algorithm. In any
case, a zone owner will have to co-ordinate an algorithm rollover between
the providers, so it isn't a big problem that CDS records can't help.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Fitzroy: Northerly or northwesterly 7 to severe gale 9, decreasing 6 at times
later. Very high at first in south, otherwise high, becoming very rough later.
Showers, thundery in south. Good, occasionally poor.