idnits 2.17.1 draft-wisser-dnssec-automation-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8901], [RFC8078], [RFC7477]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (6 March 2022) is 783 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Domain Name System Operations (dnsop) U. Wisser 3 Internet-Draft The Swedish Internet Foundation 4 Intended status: Standards Track S. Huque 5 Expires: 7 September 2022 Salesforce 6 6 March 2022 8 DNSSEC automation 9 draft-wisser-dnssec-automation-03 11 Abstract 13 This document describes an algorithm and a protocol to automate 14 DNSSEC Multi-Signer [RFC8901] "Multi-Signer DNSSEC Models" setup, 15 operations and decomissioning. Using Model 2 of the Multi-Signer 16 specification, where each operator has their own distinct KSK and ZSK 17 sets (or CSK sets), [RFC8078] "Managing DS Records from the Parent 18 via CDS/CDNSKEY" and [RFC7477] "Child-to-Parent Synchronization in 19 DNS" to accomplish this. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 7 September 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Out-Of-Scope . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Maintaining a Multi-Signer group . . . . . . . . . . . . 4 60 2.2. Secure Nameserver Operator Transition . . . . . . . . . . 4 61 3. Automation Models . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Centralized . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Decentralized . . . . . . . . . . . . . . . . . . . . . . 4 64 3.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 5 67 4.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.2.1. DS Waiting Time . . . . . . . . . . . . . . . . . . . 5 69 4.2.2. DNSKEY Waiting Time . . . . . . . . . . . . . . . . . 6 70 4.2.3. NS Waiting Time . . . . . . . . . . . . . . . . . . . 6 71 4.3. Setting up a new Multi-Signer group . . . . . . . . . . . 6 72 4.4. A Signer joins the Multi-Signer group . . . . . . . . . . 6 73 4.5. A signer leaves the Multi-Signer group . . . . . . . . . 7 74 4.6. A Signer performs a ZSK rollover . . . . . . . . . . . . 7 75 4.7. A Signer performs a CSK or KSK rollover . . . . . . . . . 8 76 4.8. Algorithm rollover for the whole Multi-Signer group. . . 8 77 5. Signers with different algorithms in one Multi-Signer 78 group . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 10. Normative References . . . . . . . . . . . . . . . . . . . . 10 84 11. Informative References . . . . . . . . . . . . . . . . . . . 11 85 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 11 86 A.1. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 11 87 A.2. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 11 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 90 1. Introduction 92 [RFC8901] describes the necessary steps and API for a Multi-Signer 93 DNSSEC configuration. In this document we will combine [RFC8901] 94 with [RFC8078] and [RFC7477] to define an automatable algorithm for 95 setting up, operating and decomissioning of a Multi-Signer DNSSEC 96 configuration. 98 One of the special cases of Multi-Signer DNSSEC is the secure change 99 of DNS operator. Using Multi-Signer Model 2 the secure change of DNS 100 operator can be accomplished. 102 1.1. Out-Of-Scope 104 In order for any Multi-Signer group to give consistent answers across 105 all nameservers, the data contents of the zone also have to be 106 synchronized (in addition to infrastructure records like NS, DNSKEY, 107 CDS etc). This content synchronization is out-of-scope for this 108 document (although there are a number of methods that can be used, 109 such as making the the same updates to each operator using their 110 respective APIs, using zone transfer in conjunction with "inline 111 signing" at each operator, etc.) 113 1.2. Notation 115 Short definitions of expressions used in this document 117 *Signer* 119 An entity signing a zone 121 *Multi-Signer Group* 123 A group of signers that sign the same zone 125 *Controller* 127 An entity controlling the multi-signer group. Used in the 128 decentralized model. 130 1.3. Requirements Language 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 2. Use Cases 137 2.1. Maintaining a Multi-Signer group 139 As described in [RFC8901] a Multi-Signer DNSSEC configuration has 140 some challenges that can be overcome with the right infrastructure 141 and following a number of steps for setup and operation. 143 In this document we describe, except for the initial trust, how the 144 steps in the Multi-Signer DNSSEC setup can be automated. 146 2.2. Secure Nameserver Operator Transition 148 Changing the nameserver operator of a DNSSEC signed zone can be 149 challenging. Currently the most common method is temporarily "going 150 insecure". This is poor for security, and for users relying on the 151 security of the zone. Furthermore, when DNSSEC is being used for 152 application security functions like DANE [RFC6698], it is critical 153 that the DNSSEC chain of trust remain unbroken during the transfer. 155 Multi-Signer DNSSEC Model 2 provides a mechanism for transitioning 156 from one nameserver operator to another without "going insecure". A 157 new operator joins the current operator in a temporary Multi-Signer 158 group. Once that is accomplished and stable the old operator leaves 159 the Multi-Signer group completing the transition. 161 3. Automation Models 163 Automation of the necessary steps can be categorized into two main 164 models, centralized and decentralized. Both have pros and cons, and 165 a zone operator should carefully choose the model that works best. 167 3.1. Centralized 169 In a centralized model the zone operator will run controller that 170 executes all steps necessary and controls all signers. 172 A centralized controller needs to have authorized access to all 173 signers. This can be achieved in a variety of different ways. For 174 example will many service providers offer access through a REST API. 175 Another possibility is access through Dynamic Update [RFC2136] with 176 TSIG authentication. 178 3.2. Decentralized 180 In the decentralized models all signers will communicate with each 181 other and execute the necessary steps on their instance only. For 182 this signers need a specialized protocol to communicate configuration 183 details that are not part of the zone data. 185 3.3. Capabilities 187 In order for any of the models to work the signer must support the 188 following capabilities. 190 1. Add DNSKEY records (without the private key) 192 2. Remove (previously added) DNSKEY record(s) 194 3. Add CDS and CDNSKEY records for keys not in the DNSKEY set 196 4. Remove (previously added) CDS and CDNSKEY records 198 5. Add CSYNC record 200 6. Remove CSYNC record 202 4. Algorithms 204 4.1. Prerequisites 206 Each Signer to be added, including the initial Signer, must meet the 207 following prerequisites before joining the Multi-Signer Group 209 1. A working setup of the zone, including DNSSEC signing. 211 2. Uses the same algorithm for DNSSEC signing as the Multi-Signer 212 group uses or will use. 214 3. Signer or controller must be able to differentiate between its 215 own keys and keys from others signers 217 4. Signer controller must be able to differentiate between NS 218 records that are updated by itself and NS records that receive 219 updates from other signers. 221 5. The domain must be covered by a CDS/CDNSKEY scanner and a CSYNC 222 scanner. Otherwise updates to the parent zone have to be made 223 manually. 225 4.2. Definitions 227 4.2.1. DS Waiting Time 229 Once the parent has picked up and published the new DS record set, 230 the any further changes MUST to be delayed until the new DS set has 231 propagated. 233 The minimum DS Waiting Time is the TTL of the DS RRset. 235 4.2.2. DNSKEY Waiting Time 237 Once the DNSKEY sets of all signers are updated, any further changes 238 MUST to be delayed until the new DNSKEY set has propagated. 240 The minimum DNSKEY Waiting Time is the maximum of all DNSKEYS TTL 241 values from all signers plus the time it takes to publish the zone on 242 all secondaries. 244 4.2.3. NS Waiting Time 246 Once the parent has picked up and published the new NS record set, 247 any further changes MUST be delayed until the new NS set has 248 propagated. 250 The minimum NS Waiting Time is the maximum of the TTL value of the NS 251 set in the parent zone and all NS sets from all signers. 253 4.3. Setting up a new Multi-Signer group 255 The zone is already authoritatively served by one DNS operator and is 256 DNSSEC signed. For full automation both the KSK and ZSK or CSK must 257 be online. 259 This would be a special case, a Multi-Signer group with only one 260 signer. 262 4.4. A Signer joins the Multi-Signer group 264 1. Confirm that the incoming Signer meets the prerequisites. 266 2. Establish a trust mechanism between the Multi-Signer group and 267 the Signer. 269 3. Add ZSK for each signer to all other Signers. 271 4. Calculate CDS/CDNSKEY Records for all KSKs/CSKs represented in 272 the Multi-Signer group. 274 5. Configure all Signers with the compiled CDS/CDNSKEY RRSET. 276 6. Wait for Parent to publish the combined DS RRset. 278 7. Remove CDS/CDNSKEY Records from all Signers. (optional) 280 8. Wait maximum of DS-Wait-Time and DNSKEY-Wait-Time 281 9. Compile NS RRSET including all NS records from all Signers. 283 10. Configure all Signers with the compiled NS RRSET. 285 11. Compare NS RRSET of the Signers to the Parent, if there is a 286 difference publish CSYNC record with NS and A and AAAA bit set 287 on all signers. 289 12. Wait for Parent to publish NS. 291 13. Remove CSYNC record from all signers. (optional) 293 4.5. A signer leaves the Multi-Signer group 295 1. Remove exiting Signer's NS records from remaining Signers 297 2. Compare NS RRSET of the Signers to the Parent, if there is a 298 difference publish CSYNC record with NS and A and AAAA bit set 299 on remaining signers. 301 3. Wait for Parent to publish NS RRSET. 303 4. Remove CSYNC record from all signers. (optional) 305 5. Wait NS-Wait-Time 307 6. Stop the exiting Signer from answering queries. 309 7. Calculate CDS/CDNSKEY Records for KSKs/CSKs published by the 310 remaining Signers. 312 8. Configure remaining Signers with the compiled CDS/CDNSKEY RRSET. 314 9. Remove ZSK of the exiting Signer from remaining Signers. 316 10. Wait for Parent to publish the updated DS RRset. 318 11. Remove CDS/CDNSKEY set from all signers. (Optional) 320 4.6. A Signer performs a ZSK rollover 322 1. The signer introduces the new ZSK in its own DNSKEY RRset. 324 2. Update all signers with the new ZSK. 326 3. Wait DNSKEY-Wait-Time 328 4. Signer can start using the new ZSK. 330 5. When the old ZSK is not used in any signatures by the signer, the 331 signer can remove the old ZSK from its DNSKEY RRset. 333 6. Remove ZSK from DNSKEY RRset of all signers. 335 4.7. A Signer performs a CSK or KSK rollover 337 1. Signer publishes new CSK / KSK in its own DNSKEY RRset. 339 2. In case of CSK, add CSK to DNSKEY set of all other Signers. 341 3. Signer signs DNSKEY RRset with old and new CSK / KSK. 343 4. Calculate new CDS/CDNSKEY RRset and publish on all signers. 345 5. Wait for parent to pickup and publish new DS RR set. 347 6. Wait DS-Wait-Time + DNSKEY-Wait-Time 349 7. Signer removes old CSK/KSK from its DNSKEY RR set. And removes 350 all signatures done with this key. 352 8. In case of CSK, remove old CSK from DNSKEY set of all other 353 signers. 355 9. Calculate new CDS/CDNSKEY RRset and publish on all signers. 357 10. Wait for parent to pickup and publish new DS RR set. 359 11. Remove CDS/CDNSKEY RR sets from all signers. 361 4.8. Algorithm rollover for the whole Multi-Signer group. 363 1. All signers publish KSK and ZSK or CSK using the new algorithm. 365 2. All signers sign all zone data with the new keys. 367 3. Wait until all signers have signed all data with the new key(s). 369 4. Add new ZSK of each signer to all other Signers. 371 5. Calculate new CDS/CDNSKEY RRset and publish on all signers. 373 6. Wait for parent to pickup and publish new DS RR set. 375 7. Wait DS-Wait-Time + DNSKEY-Wait-Time 376 8. Removes all keys and signatures which are using the old 377 algorithm. 379 9. Calculate new CDS/CDNSKEY RRset and publish on all signers. 381 10. Wait for parent to pickup and publish new DS RR set. 383 11. Remove CDS/CDNSKEY RR sets from all signers. 385 5. Signers with different algorithms in one Multi-Signer group 387 Section 2.2 of [RFC4035] states that a signed zone MUST include a 388 DNSKEY for each algorithm present in the zone's DS RRset and expected 389 trust anchors for the zone. 391 A setup where different signers use different key algorithms 392 therefore violates [RFC4035]. 394 According to Section 5.11 of [RFC6840] validators SHOULD NOT insist 395 that all algorithms signaled in the DS RRset work, and they MUST NOT 396 insist that all algorithms signaled in the DNSKEY RRset work. 398 So a Multi-Signer setup where different signers use different key 399 algorithms should still validate. 401 This could be an acceptable risk in a situation where going insecure 402 is not desirable or impossible and name servers have to be changed 403 between operators which only support distinct set of key algorithms. 405 We have to consider the following scenarios 407 *Validator supports both algorithms* 409 Validation should be stable through all stages of the multi-signer 410 algorithms. 412 *Validator supports none of the algorithms* 414 The validator will treat the zone as unsigned. Resolution should 415 work through all stages of the multi-signer algorithms. 417 *Validator supports only one of the algorithms* 419 The validator will not be able to validate the DNSKEY RR set or any 420 data from one of the signers. So in some cases the validator will 421 consider the zone bogus and reply with a SERVFAIL response code. 423 The later scenario can be mitigated, but not fully eliminated, by 424 selecting two well supported algorithms. 426 6. Acknowledgements 428 The authors would like to thank the following for their review of 429 this work and their valuable comments: Steve Crocker, Eric Osterweil, 430 Roger Murray, Jonas Andersson, Peter Thomassen. 432 7. IANA Considerations 434 8. Implementation Status 436 One implementation of a centralized controller which supports updates 437 through Dynamic DNS or REST API's of several vendors has been 438 implemented by the Swedish Internet Foundation. 440 The code can be found as part of the Multi-Signer project on Github 441 https://github.com/DNSSEC-Provisioning/multi-signer-controller 443 9. Security Considerations 445 Every step of the multi-signer algorithms has to be carefully 446 executed at the right time and date. Any failure could resolve in 447 the loss of resolution for the domain. 449 Independently of the chosen model, it is crucial that only authorized 450 entities will be able to change the zone data. Some providers or 451 software installation allow to make more specific configuration on 452 the allowed changes. All extra steps to allows as little access to 453 change zone data as possible should be taken. 455 If used correctly the multi-signer algorithm will strengthen the DNS 456 security by avoiding "going insecure" at any stage of the domain life 457 cycle. 459 10. Normative References 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, 463 DOI 10.17487/RFC2119, March 1997, 464 . 466 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 467 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 468 RFC 2136, DOI 10.17487/RFC2136, April 1997, 469 . 471 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 472 Rose, "Protocol Modifications for the DNS Security 473 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 474 . 476 [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and 477 Implementation Notes for DNS Security (DNSSEC)", RFC 6840, 478 DOI 10.17487/RFC6840, February 2013, 479 . 481 [RFC7477] Hardaker, W., "Child-to-Parent Synchronization in DNS", 482 RFC 7477, DOI 10.17487/RFC7477, March 2015, 483 . 485 [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from 486 the Parent via CDS/CDNSKEY", RFC 8078, 487 DOI 10.17487/RFC8078, March 2017, 488 . 490 11. Informative References 492 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 493 of Named Entities (DANE) Transport Layer Security (TLS) 494 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 495 2012, . 497 [RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D. 498 Blacka, "Multi-Signer DNSSEC Models", RFC 8901, 499 DOI 10.17487/RFC8901, September 2020, 500 . 502 Appendix A. Change History 504 A.1. Change from 01 to 02 506 1. Trying to fix wording to be more precise 508 2. Added algorithm for ZSK rollover 510 3. Added algorithm for KSK rollover 512 4. Added algorithm for algorithm rollover 514 A.2. Change from 02 to 03 516 1. Fix sequnce of steps in the joining procedure 518 2. Excplicit handling of CSK cases in CSK/ KSK rollover 520 Authors' Addresses 522 Ulrich Wisser 523 The Swedish Internet Foundation 524 Box 92073 525 SE-12007 Stockholm 526 Sweden 527 Email: ulrich@wisser.se 528 URI: https://www.internetstiftelsen.se 530 Shumon Huque 531 Salesforce 532 415 Mission Street, 3rd Floor 533 San Francisco, CA 94105 534 United States of America 535 Email: shuque@gmail.com