Internet DRAFT - draft-thomassen-dnsop-mske
draft-thomassen-dnsop-mske
DNSOP Working Group P. Thomassen
Internet-Draft Secure Systems Engineering, deSEC
Updates: 4034 (if approved) 24 October 2022
Intended status: Standards Track
Expires: 27 April 2023
DNSSEC Multi-Signer Key Exchange (MSKE)
draft-thomassen-dnsop-mske-00
Abstract
Answering DNSKEY/CDS/CDNSKEY queries in an [RFC8901] multi-signer
DNSSEC configuration requires all operators to serve not only their
own public key information, but also include each other's public
keys. This ensures that clients obtain a consistent view of the
DNSSEC configuration regardless of who is answering a given query.
In order to enable operators to import the keys needed for assembling
these responses, a method for discovering them is necessary.
This document specifies how DNS operators can announce which are the
keys they intend to use for signing a given zone (DNSKEY) and which
keys are designated for secure entry into the zone (CDS/CDNSKEY). It
further introduces the CNS record type to facilitate proactive
discovery of the aforementioned signals. Taken together, these parts
function as an authenticated multi-signer key-exchange (MSKE) scheme.
This MSKE mechanism uses the signaling mechanism introduced in
[I-D.ietf-dnsop-dnssec-bootstrapping] to complete the automated
workflows described in [I-D.ietf-dnsop-dnssec-automation].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 April 2023.
Thomassen Expires 27 April 2023 [Page 1]
Internet-Draft mske October 2022
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Conceptual Overview . . . . . . . . . . . . . . . . . . . . . 3
2.1. Key Announcement . . . . . . . . . . . . . . . . . . . . 4
2.2. Triggering Initial Key Synchronization . . . . . . . . . 4
2.2.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. Properties . . . . . . . . . . . . . . . . . . . . . 5
2.3. Parent-side Updates . . . . . . . . . . . . . . . . . . . 5
3. The CNS Record Type . . . . . . . . . . . . . . . . . . . . . 6
4. Multi-Signer Key Exchange Protocol . . . . . . . . . . . . . 6
4.1. Key Announcements . . . . . . . . . . . . . . . . . . . . 6
4.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Key Discovery . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Parent-side Updates . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Normative References . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Change History (to be removed before publication) . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
In comparison to single-signer DNSSEC deployments, multi-signer
setups as described in [RFC8901] come with additional coordination
overhead. This overhead entails
* the key exchange process that is needed so that each provider can
serve a joint record set reflecting all relevant providers' DNSSEC
keys when responding to a DNSKEY or CDS/CDNSKEY query,
Thomassen Expires 27 April 2023 [Page 2]
Internet-Draft mske October 2022
* timing coordination when updating the DNSSEC confguration
(similarly to what's needed when performing a key rollover, see
[RFC7583] for details).
While the logistics and timing considerations of adding and removing
a DNSSEC signer to/from a given constellation are described in
[I-D.ietf-dnsop-dnssec-automation], an automatable method for the key
exchange step has not been specified so far. It is thus proposed
with this document.
Readers are expected to be familiar with DNSSEC, including [RFC4033],
[RFC4034], [RFC4035], [RFC6781], [RFC7344], [RFC7477], [RFC7583], and
[RFC8901].
1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "*SHALL NOT*",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "*NOT RECOMMENDED*", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Conceptual Overview
DNS resolvers may direct queries against any nameserver contained in
a zone's NS record set. When asking (for instance) for an A record
set, the response (including the RRSIG signature) may thus be
retrieved from one nameserver, while the DNSKEY record set required
for validation may be retrieved from another nameserver (and hence
provider). This is by design: Resolvers do not have any notion of
multi-provider concepts; the multi-signer models described in
[RFC8901] just look like multi-key setups to them.
DNSSEC multi-signer setups thus require that a DNSKEY response
contains all keys a validating resolver may need to validate an RRSIG
signature from that zone, irrespective of whether that RRSIG is
obtained from the same nameserver/provider as the DNSKEY record set.
To allow validation to work properly, the DNSKEY RRset therefore must
be the union of all of the DNSKEY record sets that each provider
would serve if they were the only (signing) provider.
Similarly, CDS/CDNSKEY record sets published on any of the
nameservers for the purpose of automated DS record maintenance
([RFC7344][RFC8078][I-D.ietf-dnsop-dnssec-bootstrapping]) are
required to be the union across all signers in order to prevent
accidents caused by a single provider publishing an inconsistent
RRset ([I-D.thomassen-dnsop-cds-consistency]).
Thomassen Expires 27 April 2023 [Page 3]
Internet-Draft mske October 2022
2.1. Key Announcement
In order for the participating providers to discover each others'
DNSKEY/CDS/CDNSKEY records for inclusion in their responses,
providers need to signal what their single-provider record sets would
be. Specifically, each provider needs to separately announce
* their KSK (or CSK) public keys for inclusion in CDS/CDNSKEY record
sets, and
* their ZSK (or CSK) public keys for inclusion in the DNSKEY record
set.
Ideally, the mechanism would be authenticated and in-band, and allow
each provider to import these records in a straightforward manner.
In particular, no heuristics should need to be applied to determine
the usage mode of any given key. The publishing provider, having
ultimate knowledge of how each key is used, should instead make this
distinction explicit in what they publish.
(This is in contrast to inference methods, such as querying the
DNSKEY RRset from each provider and guessing which keys are used for
KSK and/or ZSK purposes. Such methods do not adequately cover edge
cases such as distinguishing a standby key from a retired key that
needs to be cleaned up, or a key that looks like a KSK but also signs
another RRset.)
The signaling mechanism described in
[I-D.ietf-dnsop-dnssec-bootstrapping] Section 2 provides a suitable
framework for these key announcements.
2.2. Triggering Initial Key Synchronization
Once providers have put their key announcements in place, they need
to be made aware of each other so that keys can be retrieved,
validated, and included in each provider's local copy of the
DNSKEY/CDS/CDNSKEY record sets.
To see how this can work, consider the process of onboarding a new
signing provider. Suppose that the zone is configured both at the
existing and the new provider(s), with equivalent contents as far as
non-DNSSEC records are concerned (that is, same A/MX/CNAME/TXT/...
records).
Thomassen Expires 27 April 2023 [Page 4]
Internet-Draft mske October 2022
As the new provider can only be added to the NS record set once the
key exchange has concluded, the new provider's nameservers are not
yet part of it and cannot be discovered by looking at the NS RRset.
The NS record set therefore is not a suitable starting point for
provider discovery.
2.2.1. Mechanism
Discovery can be achieved by adding a new record set which holds the
prospective set of NS hostnames. This is similar to how the CDS
record set holds the prospective DS records. Like the CDS RRset, it
also resides on the child side of the zone cut, and it is used for
scanning (albeit peer-to-peer, not parent-child). The type of the
new record set is therefore called CNS.
To indicate that the set of providers is about to change, the zone
administrator adds a CNS record set to the zone at all involved
providers (both old and new). The record set is the same at all
providers (just like any regular record set in the zone, such as A/
MX/...).
Providers can detect that a CNS record set has been created, and
subsequently start collecting keys (see Section 2.1) from the other
providers' nameservers, as extracted from the CNS record set.
2.2.2. Properties
The process is symmetrical in two ways: (1) it works the same way for
old and new signers alike (both existing and incoming provider(s) see
the same CNS record set); (2) it covers both additional and removal
of providers. It therefore also covers transitions from one single
provider to another single provider (with a temporary multi-signer
period in between).
If necessary, the method can further be used to trigger a key re-sync
without changing providers (such as when revoking a key). This is
achieved by copying the NS records into the CNS record set, upon
which key collection would occur.
2.3. Parent-side Updates
After importing, each provider can periodically check whether the key
exchange has converged. This can be done by verifying that the
zone's DNSKEY/CDS/CDNSKEY record sets as served by the other
providers are equivalent to the joint set seen locally (containing
both local and imported keys). As the process is fully transparent,
it can also be externally observed.
Thomassen Expires 27 April 2023 [Page 5]
Internet-Draft mske October 2022
In case convergence does not occur for a while, any provider (or
other observer) MAY detect which keys are missing on whose
nameservers (by comparing each apex DNSKEY record set to everyone's
announced keys, see Section 2.1). Detecting providers can easily
relay this information to the zone owner. This allows the zone owner
to proactively tackle the problem (e.g. by contacting customer
support), instead of experiencing a silent or intransparent failure.
Once convergence is confirmed and the parent has updated the DS
record accordingly (e.g. after observing the new CDS/CDNSKEY
records), the NS record set can be replaced with the records from the
CNS RRset. Finally, the updated NS RRset can be conveyed to the
parent for updating the delegation (e.g. via CSYNC, or EPP if
available to one of the providers).
From the parent's perspective, this process is identical to how DS
and NS records would be updated in a single-provider setup. No
dedicated functionality specific to multi-signer setups is required.
3. The CNS Record Type
During a multi-provider configuration process, CNS records indicate
which are the NS records that are expected to be in place once the
process finishes. As such, record parameters, value constraints, and
wire as well as presentation format are the same as for NS records
([RFC1034] Section 3.3.11).
This is similar to how CDS records indicate the prospective DS
records, and thus share formats and constraints with the DS record
type.
4. Multi-Signer Key Exchange Protocol
This section specifies the details of how each provider publishes
their keys and how they can be discovered by peers.
The signaling-related terminology in this section is as defined in
[I-D.ietf-dnsop-dnssec-bootstrapping].
4.1. Key Announcements
To indicate that a provider is willing to participate in a multi-
signer key exchange for a given zone, iterate over the zone's DNSKEY
records for which the provider holds the private key. For each such
key, execute all of the following steps:
Thomassen Expires 27 April 2023 [Page 6]
Internet-Draft mske October 2022
1. Mark the key for CDS/CDNSKEY signaling if the provider intends to
use the key as a secure entry point into the zone (= would want
it referenced in the delegation's DS record set);
2. Mark the key for DNSKEY signaling if the provider intends to
sign, with the corresponding private key, any RRsets besides the
apex DNSKEY RRset.
Next, publish CDS and CDNSKEY records corresponding to (1) and DNSKEY
records corresponding to (2) under the zone's Signaling Domains using
Signaling Type "_multi".
Existing use of DNSKEY and CDS/CDNSKEY records is specified at the
apex only ([RFC4034], Section 2.1.1 and [RFC7344], Section 4.1,
respectively). This protocol extends the use of these record types
to non-apex owner names for the purposes of DNSSEC MSKE. To exclude
the possibility of semantic collision, there MUST NOT be a zone cut
at a the Signaling Records' owner name.
4.1.1. Example
Consider Provider 1 with nameservers ns1.example.net and
ns2.example.net. To prepare a multi-signer key exchange for the zone
example.co.uk hosted on these nameservers, the provider starts from
the list of DNSKEY records for which the provider holds the private
key.
Iterating over all these DNSKEYs, the provider publishes CDS/CDNSKEY
records for each key that it would like promoted to the delegation's
DS record set (KSK-like use), at the following owner names:
_multi.example.co.uk._signal.ns1.example.net
_multi.example.co.uk._signal.ns2.example.net
Iterating over the same list, the provider also publishes a DNSKEY
record for each key that it wants to use for signing any RRsets
besides the apex DNSKEY RRset (ZSK-like use), at the same owner
names.
The records are accompanied by RRSIG records created using the key(s)
of the respective Signaling Zone.
Provider 2 (with nameservers under example.org) follows the same
steps to announce their multi-signer keys, under the owner names:
_multi.example.co.uk._signal.ns1.example.org
_multi.example.co.uk._signal.ns2.example.org
Thomassen Expires 27 April 2023 [Page 7]
Internet-Draft mske October 2022
[TODO Strictly, if Provider 1 knows that a key will ONLY be used as a
KSK and NOT for signing any other records, it doesn't need to be
imported by other providers and thus does not need to be announced
here as a DNSKEY. -- This is because the key is needed only for
verifying the target zone's DNKSEY RRset when retrieved from Provider
1, and in this case, it will be included in the apex DNSKEY RRset
itself. To validate a DNSKEY RRset retrieved from Provider 2, the
KSK of Provider 1 is not needed.]
4.2. Key Discovery
When a provider finds that the zone owner has created a CNS record
set, the provider creates an "external nameserver list" by filtering
the NS hostnames contained in the CNS RRset, removing those which are
under the provider's control. The remaining list represent the
subset of prospective NS hostnames operated by other providers.
To import the other providers' DNSSEC keys, the provider starts out
from initial DNKSEY/CDS/CDNSKEY record sets that only reference keys
for which the provider holds the private key. These record sets are
called "local RRsets" below.
Next, for each hostname in the "external nameserver list", the
provider constructs the owner names of the corresponding Signaling
Records and queries CDS, CDNSKEY, and DNSKEY records at these owner
names. Answers that can be DNSSEC-validated are added to the
corresponding "local RRset".
4.2.1. Example
The zone owner is generally tasked with keeping the zone contents at
all provider in sync. It is thus the first step for the zone owner
to ensure that general zone content (such as A/MX/TXT records) is
equal everywhere.
Next, the zone owner adds the following record set to the zone
configuration at both Provider 1 and Provider 2:
example.co.uk. 3600 IN CNS ns1.example.net.
example.co.uk. 3600 IN CNS ns2.example.net.
example.co.uk. 3600 IN CNS ns1.example.org.
example.co.uk. 3600 IN CNS ns2.example.org.
When Provider 1 detects the CNS RRset, Provider 1 creates the
"external nameserver list" by removing their own nameservers. The
list then contains the hostnames ns1.example.org and ns2.example.org,
which belong to Provider 2.
Thomassen Expires 27 April 2023 [Page 8]
Internet-Draft mske October 2022
Provider 1 then uses these hostnames, the target zone name and the
Signaling Type "_multi" to query the CDS/CDNSKEY/DNSKEY Signaling
Records from the following owner names:
_multi.example.co.uk._signal.ns1.example.org
_multi.example.co.uk._signal.ns2.example.org
Starting out from DNSKEY/CDS/CDNSKEY "local RRsets" that only have
Provider 1's keys, Provider 1 validates the received answers and adds
them to the corresponding local RRset.
Provider 2 performs the same steps to import Provider 1's keys, by
querying and validating the CDS/CDNSKEY/DNSKEY records from the
following owner names:
_multi.example.co.uk._signal.ns1.example.net
_multi.example.co.uk._signal.ns2.example.net
4.3. Parent-side Updates
Multi-signer setups are not in any way special from the parent's
perspective: Like for any client (such as resolvers), they merely
look like a multi-key setup.
Once convergence has been detected, existing protocols can therefore
be used for DS management automation (via CDS/CDNSKEY,
[RFC7344][RFC8078][I-D.ietf-dnsop-dnssec-bootstrapping])
Once providers detect that the DS record set has been updated
accordingly, the zone's NS record set can be updated to reflect the
changes indicated by the CNS RRset. This is most easily done wy
overwriting the NS records set with the contents of the CNS RRset.
Finally, existing protocols can be used to propagate the NS (and
possibly glue) changes to the parent (e.g. via CSYNC, [RFC7477]).
If one of the participating providers is also a registrar, the EPP
protocol may be used as well [RFC5730].
5. Security Considerations
TODO
6. Normative References
[I-D.ietf-dnsop-dnssec-automation]
Wisser, U. and S. Huque, "DNSSEC automation", Work in
Progress, Internet-Draft, draft-ietf-dnsop-dnssec-
Thomassen Expires 27 April 2023 [Page 9]
Internet-Draft mske October 2022
automation-00, 24 May 2022,
<https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-
automation-00.txt>.
[I-D.ietf-dnsop-dnssec-bootstrapping]
Thomassen, P. and N. Wisiol, "Automatic DNSSEC
Bootstrapping using Authenticated Signals from the Zone's
Operator", Work in Progress, Internet-Draft, draft-ietf-
dnsop-dnssec-bootstrapping-02, 17 August 2022,
<https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-
bootstrapping-02.txt>.
[I-D.thomassen-dnsop-cds-consistency]
Thomassen, P., "Consistency for CDS/CDNSKEY and CSYNC is
Mandatory", Work in Progress, Internet-Draft, draft-
thomassen-dnsop-cds-consistency-02, 24 October 2022,
<https://datatracker.ietf.org/api/v1/doc/document/draft-
thomassen-dnsop-cds-consistency/>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>.
Thomassen Expires 27 April 2023 [Page 10]
Internet-Draft mske October 2022
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781,
DOI 10.17487/RFC6781, December 2012,
<https://www.rfc-editor.org/info/rfc6781>.
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344,
DOI 10.17487/RFC7344, September 2014,
<https://www.rfc-editor.org/info/rfc7344>.
[RFC7477] Hardaker, W., "Child-to-Parent Synchronization in DNS",
RFC 7477, DOI 10.17487/RFC7477, March 2015,
<https://www.rfc-editor.org/info/rfc7477>.
[RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking,
"DNSSEC Key Rollover Timing Considerations", RFC 7583,
DOI 10.17487/RFC7583, October 2015,
<https://www.rfc-editor.org/info/rfc7583>.
[RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from
the Parent via CDS/CDNSKEY", RFC 8078,
DOI 10.17487/RFC8078, March 2017,
<https://www.rfc-editor.org/info/rfc8078>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D.
Blacka, "Multi-Signer DNSSEC Models", RFC 8901,
DOI 10.17487/RFC8901, September 2020,
<https://www.rfc-editor.org/info/rfc8901>.
Appendix A. Change History (to be removed before publication)
* draft-thomassen-dnsop-mske-00
| Initial public draft.
Author's Address
Peter Thomassen
Secure Systems Engineering, deSEC
Berlin
Germany
Email: peter.thomassen@securesystems.de
Thomassen Expires 27 April 2023 [Page 11]
