DNS Delegation P. Homburg Internet-Draft W. Toorop Updates: 4034, 4035 (if approved) NLnet Labs Intended status: Standards Track 16 January 2025 Expires: 20 July 2025 Incrementally Deployable DNSSEC Delegation draft-homburg-deleg-incremental-dnssec-00 Abstract This document proposes a DNSSEC delegation mechanism that complements [I-D.homburg-deleg-incremental-deleg]. In addition this mechanism simplifies multi-signer setups by removing the need to coordinate for signers during key rollovers. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-homburg-deleg-incremental- dnssec/. Discussion of this document takes place on the deleg Working Group mailing list (mailto:dd@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dd/. Subscribe at https://www.ietf.org/mailman/listinfo/dd/. Source for this draft and an issue tracker can be found at https://github.com/NLnetLabs/incremental-dnssec. 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." Homburg & Toorop Expires 20 July 2025 [Page 1] Internet-Draft incremental-dnssec January 2025 This Internet-Draft will expire on 20 July 2025. Copyright Notice Copyright (c) 2025 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. Incremental Deleg . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. New parameters . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. The ds parameter . . . . . . . . . . . . . . . . . . . . 6 2.2. The dnskeyref parameter . . . . . . . . . . . . . . . . . 6 3. Validator behavior . . . . . . . . . . . . . . . . . . . . . 6 4. Signer behavior . . . . . . . . . . . . . . . . . . . . . . . 7 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. One ds parameter that is part of a delegation . . . . . . 8 5.2. One separate DELEG record with a ds parameter . . . . . . 9 5.3. One separate DELEG record with a dnskeyref parameter . . 9 5.4. Two operators with dnskeyref parameters . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction This document describes a DNSSEC delegation mechanism that complements [I-D.homburg-deleg-incremental-deleg]. In particular, this mechanism makes it possible to store the contents of DS records as 'ds' parameters in SVCB-style records. This way, a single mechanism can specify both name servers and DNSSEC delegations. Homburg & Toorop Expires 20 July 2025 [Page 2] Internet-Draft incremental-dnssec January 2025 In addition to a replacement for DS records, this document also introduces a 'dnskeyref' parameter that provides more flexibility and reduces the need to coordinate both for key rollovers and for multi- signer setups. There are two main problems with the current DS record. The first is a DS record refers to a key in a DNSKEY RRset. Updating this keys (during a key rollover) requires updating the corresponding DS record. At the moment there is no widespread mechanism to update DS records automatically. However, even if such an update mechanism would become widespread, the signer also has to track to propagation of the new DS record to the secondaries of the parent zone. This is needed to make sure that all old DS records are expired in caches before moving to the next stage of a key roll. The second problem is that DS records enforce the use of a single DNSKEY RRset (at the apex of the zone). This means that in a multi- signer setup, signers have to coordinate when rolling their signing keys. There is one minor problem that can be solved as well. Currently every signed zone has to have a DNSKEY RRset at the apex. If a collection of zones share the same keys then this can be burden to maintain. The solution to these problems is to introduce a dnskeyref parameter that contains the names of DNSKEY RRsets that are allowed to sign a zone. This extra level of indirection avoids the need to involve the parent during key rolls. Multiple DNSKEY RRsets make it possible to perform key rolls in a multi-signer setup without coordination. Finally, this allows a single DNSKEY RRset to be used for multiple domains. The charter for the Deleg working group has the following: | The DNS protocol has limited ability for authoritative servers to | signal their capabilities to recursive resolvers. In part, this | stems from the lack of a mechanism for parents (often registries) | to specify additional information about child delegations (often | registrants) beyond NS, DS, and glue records. Further | complicating matters is the similar lack of a mechanism for a | registrant to signal that the operation of a delegation point is | being outsourced to a different operator, leaving a challenge when | operators need to update parental information that is only in the | control of the child. Data is often out of synchronization | between parents and children, which causes significant operational | problems. Homburg & Toorop Expires 20 July 2025 [Page 3] Internet-Draft incremental-dnssec January 2025 The main focus to date has been on making it possible to update the name servers of a delegation without involving the registrant. However, DNSSEC has a similar problem. The introduction of the dnskeyref parameter make it possible to manage DNSSEC without involving the registrant. One extra feature that becomes possible with the use of SVCB-style records is to let the zone manage downgrade attacks. By introducing ds or dnskeyref parameters at different priority level, the zone can signal which algorithm is preferred. This document updates Section 2.1.1 of [RFC4034] in the following way: the sentence "If bit 7 has value 0, then the DNSKEY record holds some other type of DNS public key and MUST NOT be used to verify RRSIGs that cover RRsets." is replaced by "If bit 7 has value 0, then the DNSKEY record holds some other type of DNS public key and can be used to verify RRSIGs that cover RRsets if required." This document updates Section 5.3.1 of [RFC4035] and replaces the sentence "The RRSIG RR's Signer's Name field MUST be the name of the zone that contains the RRset." with "The RRSIG RR's Signer's Name field MUST be the name of any DNSKEY RRset that is allowed to sign the zone." 1.1. Incremental Deleg This section is to be removed before publishing as an RFC. This document builds on [I-D.homburg-deleg-incremental-deleg] so examples will show _deleg labels. This document does however assume a new SVCB-style type called DELEG to be able to make clear that some semantics are different from SVCB records. The mechanisms described in this document can work with [I-D.wesplaap-deleg] as well. However, this will create a deployment issue. If a validator that implements this document and [I-D.wesplaap-deleg] forwards requests to a recursive resolver that does not implement [I-D.wesplaap-deleg] then validation will fail if the delegation uses DELEG records. In contrast the same setup but then with [I-D.homburg-deleg-incremental-deleg] will work. Homburg & Toorop Expires 20 July 2025 [Page 4] Internet-Draft incremental-dnssec January 2025 1.2. Terminology 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. This document follows terminology as defined in [RFC9499]. Throughout this document we will also use terminology with the meaning as defined below: Incremental deleg: The delegation mechanism as specified in [I-D.homburg-deleg-incremental-deleg]. Incremental delegation: A delegation as specified in [I-D.homburg-deleg-incremental-deleg]. AliasMode: An SVCB mode as specified in [RFC9460]. ServiceMode: An SVCB mode as specified in [RFC9460]. SvcParamKey: An SVCB field as specified in [RFC9460]. SvcParamValue: An SVCB field as specified in [RFC9460]. 2. New parameters Two new SVCB-style parameters are introduced: ds and dnskeyref. To limit validation resources and avoid accidentally delegating security, these two parameters are not valid after following an SVCB- style record in AliasMode. For DELEG records, these parameters are allowed to be added to DELEG records in AliasMode. To increase flexibility, a DELEG record in ServiceMode can be created with just ds or dnskeyref parameters but without name server delegation. In that case the TargetName has to be set to ".". Unlike SVCB records, for DELEG we allow mixing of AliasMode and ServiceMode records. Homburg & Toorop Expires 20 July 2025 [Page 5] Internet-Draft incremental-dnssec January 2025 2.1. The ds parameter The ds parameter puts the equivalent of multiple DS records in one parameter. To simplify parsing, the presentation format is a space separated list of strings where each string is in the form :::. The parts key-tag, algorithm, digest-type and digest have their meaning and encoding as described for the presentation format of the DS record (See [RFC4034], Section 5.3). A parameters start with a 2-octet field that contains the SvcParamKey following by a 2-octet field containing the length of the SvcParamValue. For the ds parameter, the SvcParamValue field consists of a sequence of DS record RDATA octet sequences prefixed by a 1-octet length field. The length field contains the length of the DS record RDATA. The encoding of the RDATA octet sequence is the same as for an equivalent DS record (with the exact same owner name as the SVCB- style record that contains the ds parameter). 2.2. The dnskeyref parameter The dnskeyref parameter names one or more DNSKEY RRsets. The presentation format of the value is a space separated list of DNS names. The wire format starts with a 2-octet field that contains that SvcParamKey followed by a 2-octet filed than contains the length of SvcParamValue. For dnskeyref, the SvcParamValue consists of just a concontenated list of uncompressed DNS names in wire format. DNS names are self terminating so there is no need for extra length fields. 3. Validator behavior When following a delegation, a validator MUST first look for an Incremental delegation. If presence or absence is not DNSSEC Secure (i.e., the status is Insecure, Bogus or Indeterminate) then the child is not secure and the algorithm stops here. If absence of an Incremental delegation is proven to be Secure then then validator MAY continue validating using DS records. Homburg & Toorop Expires 20 July 2025 [Page 6] Internet-Draft incremental-dnssec January 2025 If a secure Incremental delegation is found then the validator MUST ignore any DS records and solely rely on what is found in the Incremental deleg records. If the Incremental deleg records contain no ds or dnskeyref parameters or these do not lead to any key with an algorithm that the validator supports then the delegation is considered insecure. A validator MUST NOT use any ds or dnskeyref parameters found after following an SVCB-style record in AliasMode. Restricting ds and dnskeyref to the top level is essential in preventing a DNS operator (who is supposed to only serve a zone, not sign it) from adding additional ds or dnskeyref parameters. To support protection against downgrade attacks, a validator SHOULD consider only SVCB-style records with the highest priority that either have a ds parameter that has a least one algrithm supported by the validator or in the case of dnskeyref, a DNSKEY RRset that contains at least one key with an algorithm that is supported. After selecting priority level, the validator uses any ds parameters to validate the DNSKEY RRset the apex of the child zone. The DNSKEY RRsets that dnskeyref paramters refer need to be DNSSEC Secure to be used. Any DNSKEY RRsets that are not DNSSEC Secure according to the validator MUST be ignored. [Note, to be removed for publication. Should the validator check if the Zone Key flag is zero if the DNSKEY RRset is not at the apex. For now assume that it is just like the SEP flag and can be ignored.] To limit validator resources, when validating a name that refers to a DNSKEY RRset, the validator should only use ds parameters (and DS records) and ignore any dnskeyref parameters. Validator SHOULD allow for a DNAME and CNAME chain of reasonable length when resolving a name to a DNSKEY RRset. Now that there are multiple DNSKEY RRsets that may be used to sign an RRset, the validator uses the Signer's Name in a signature to select a DNSKEY RRset to validate the signature. If the name does not match any of the DNSKEY RRset selected in the previous step then the signature MUST be ignored. 4. Signer behavior Signer MUST put ds and dnskeyref parameters only in DELEG records at an Incremental delegation and not in SVCB-style records that follow a DELEG record in AliasMode. Homburg & Toorop Expires 20 July 2025 [Page 7] Internet-Draft incremental-dnssec January 2025 The ds parameter affects signers in one small way: the priority system of SVCB-style records can be used to provide protection again downgrades. The signer can put a ds parameter with a more secure algorithm in a DELEG record with a higher priority and expect fallback to the less secure algorithm only if the validator does not understand the more secure algorithm. The dnskeyref parameter requires that the validator puts the name of the DNSKEY RRset in the Signer's Name field of the signature. This is a small but significant change to how signers operate. The DNSKEY RRset MUST be DNSSEC Secure and the validation chain MUST only involve ds parameters or DS records. In addition DNSKEY records that are not at the apex of a zone MUST have the Zone Key flag set to 0 (bit 7 of the flags field, see [RFC4034], Section 2.1.1) The dnskeyref parameter also supports downgrade protection but has a number of additinal features that can be used by signers. The first is that because dnskeyref directly refers to a DNSKEY RRset there is no longer any need for Key Signing Keys (KSK). Those DNSKEY RRsets only contain Zone Signing Keys (ZSK). This means that KSK rollovers are no longer necessary. It is also no longer necessary to coordinate with the parent zone for key rollovers. The second is that dnskeyref can refer to a DNSKEY RRset that is used to sign multiple zones. Zones do no need to have their own copies of key material. Instead a single DNSKEY RRset can be used for as many zones as needed. Third, in a multi-signer setup, each signer can maintain its own DNSKEY RRset independent of other signers. This means that each signer can perform key rollovers without any need to coordinate with other signers. 5. Examples 5.1. One ds parameter that is part of a delegation $ORIGIN example. @ IN SOA ns zonemaster ... customer1._deleg IN DELEG 1 ( ns.customer1 ipv4hint=198.51.100.1,203.0.113.1 ipv6hint=2001:db8:1::1,2001:db8:2::1 ds=60485:5:1:2BB183AF5F22588179A53B0A98631FAD1A292118 ) Figure 1: One ds parameter that is part of a delegation Homburg & Toorop Expires 20 July 2025 [Page 8] Internet-Draft incremental-dnssec January 2025 5.2. One separate DELEG record with a ds parameter $ORIGIN example. @ IN SOA ns zonemaster ... customer2._deleg IN DELEG 0 ns.operator1 IN DELEG 1 ( . ds="60485:5:1:2BB183AF5F22588179A53B0A98631FAD1A292118 370:13:2:BE74359954660069D5C63D200C39F5603827D7DD02B56F120EE9F3A86764247C" ) Figure 2: One separate DELEG record with a ds parameter 5.3. One separate DELEG record with a dnskeyref parameter $ORIGIN example. @ IN SOA ns zonemaster ... customer3._deleg IN DELEG 0 ns.operator1 IN DELEG 1 ( . dnskeyref=customer3.keys.operator1 ) Figure 3: One separate DELEG record with a dnskeyref parameter 5.4. Two operators with dnskeyref parameters $ORIGIN example. @ IN SOA ns zonemaster ... customer4._deleg IN DELEG 1 ( ns.operator1 dnskeyref=customer4.keys.operator1 ) IN DELEG 1 ( ns.operator2 dnskeyref=customer-keys.operator3 ) Figure 4: Two operators with dnskeyref parameters 6. Security Considerations The ds parameter is a slight improvement over the DS record because it allows SVCB priorities to be used for downgrade protection. Otherwise, the semantics are the same. This relies on the restriction that ds (and dnskeyref) parameters can only appear the top level and not after following an SVCB-style record in AliasMode. Homburg & Toorop Expires 20 July 2025 [Page 9] Internet-Draft incremental-dnssec January 2025 The dnskeyref parameter breaks the traditional chain semantics of DNSSEC. With the ds parameter (or the DS record) the validity of a signature depends only on a chain of cryptographic primitives. With dnskeyref, a DNS lookup is inserted. This DNS lookup is protected by a traditional DNSSEC chain, but the presence of the name means that it is no longer a cryptographic chain. This trade-off between struct security and flexibility is left to the zone operator. A new risk that needs to be considered is old and forgotten dnskeyref parameters. Old DS records or ds parameters are mostly safe. An attacker can only assume then if the attacker can obtain the private key that can sign for the public key that the DS record or ds parameter refers to. This is not impossible but very unlikely. And the use of hardware security modules (HSM) can make this almost impossible. In contrast if a dnskeyref refers to a name in a forgotten domain and the registration of the domain is expired then an attacker may register the name and set up a DNSKEY RRset at the name listed in the dnskeyref parameter. The risk of this can be reduced by two operational practices. The first is to put the dnskeyref parameter in the same (AliasMode) DELEG record that provides the name server delegation. This will make it likely that dnskeyref parameter will be removed once the name servers no long serve the zone. The second practice is that domains that allow registrations (mostly top level domains (TLD) but also others) could install a policy that a dnskeyref parameter MUST refer to a DNSSEC Secure DNSKEY RRsets. Additionally each DNSKEY RRset that is referred to by a dnskeyref parameter has to be used to sign the zone as served by at least one of the name servers that serves the zone. This makes it possible to detect forgotten or misconfigured dnskeyref paramters early on. 7. IANA Considerations Per [RFC9460], IANA is requested to add the following entry to the DNS "Service Parameter Keys (SvcParamKeys)" registry: Homburg & Toorop Expires 20 July 2025 [Page 10] Internet-Draft incremental-dnssec January 2025 +========+===========+===============+===========+============+==+ | Number | Name | Meaning | Reference | Change | | | | | | | Controller | | +========+===========+===============+===========+============+==+ | TBD | ds | DNSSEC | [this | IETF | | | | | delegations | document] | | | +--------+-----------+---------------+-----------+------------+--+ | TBD | dnskeyref | Names of | [this | IETF | | | | | DNSKEY RRsets | document] | | | +--------+-----------+---------------+-----------+------------+--+ Table 1: Entry in the Service Parameter Keys (SvcParamKeys) registry 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [I-D.homburg-deleg-incremental-deleg] Homburg, P., Wicinski, T., van Zutphen, J., and W. Toorop, "Incrementally Deployable Extensible Delegation for DNS", Work in Progress, Internet-Draft, draft-homburg-deleg- incremental-deleg-01, 8 January 2025, . [I-D.wesplaap-deleg] April, T., Špaček, P., Weber, R., and Lawrence, "Extensible Delegation for DNS", Work in Progress, Internet-Draft, draft-wesplaap-deleg-01, 21 October 2024, . [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, . Homburg & Toorop Expires 20 July 2025 [Page 11] Internet-Draft incremental-dnssec January 2025 [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, . [RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, . [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, . Acknowledgments Jens Finkhäuser, Havard Eidnes, Edward Lewis, Petr Špaček, Johan Stenstam Authors' Addresses Philip Homburg NLnet Labs Email: philip@nlnetlabs.nl Willem Toorop NLnet Labs Email: willem@nlnetlabs.nl Homburg & Toorop Expires 20 July 2025 [Page 12]