idnits 2.17.1 draft-wisser-dnssec-automation-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (21 February 2021) is 1157 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 (~~), 2 warnings (==), 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: 25 August 2021 Salesforce 6 21 February 2021 8 DNSSEC automation 9 draft-wisser-dnssec-automation-01 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. It primarily deals with Model 2 of 16 the Multi-Signer specification, where each operator has their own 17 distinct KSK and ZSK sets (or CSK sets). It makes use of [RFC8078] 18 "Managing DS Records from the Parent via CDS/CDNSKEY" and [RFC7477] 19 "Child-to-Parent Synchronization in 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 25 August 2021. 38 Copyright Notice 40 Copyright (c) 2021 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 Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 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. Running a multi-signer setup . . . . . . . . . . . . . . 3 60 2.2. Secure change of name server operator . . . . . . . . . . 3 61 3. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Setting up a new multi-signer group . . . . . . . . . . . 4 63 3.2. Configuration . . . . . . . . . . . . . . . . . . . . . . 4 64 3.3. A new signer joins the multi-signer group . . . . . . . . 4 65 3.3.1. Prerequisites . . . . . . . . . . . . . . . . . . . . 4 66 3.3.2. Steps for joining . . . . . . . . . . . . . . . . . . 4 67 3.4. A signer leaves the multi-signer group . . . . . . . . . 5 68 4. Automation . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Centralized . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.2. Decentralized . . . . . . . . . . . . . . . . . . . . . . 6 71 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 75 9. Informative References . . . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 [RFC8901] describes the necessary steps and API for a multi-signer 81 DNSSEC configuration. In this document we will combine [RFC8901] 82 with [RFC8078] and [RFC7477] to define a fully automatable algorithm 83 for setting up, operating and decomissioning of a multi-signer DNSSEC 84 configuration. 86 One of the special cases of multi-signer DNSSEC is actually the 87 secure change of DNS operator. 89 1.1. Out-Of-Scope 91 In order for any multi-signer group to give consistent answers across 92 all nameservers, the data contents of the zone also have to be 93 synchronized (in addition to infrastructure records like NS, DNSKEY, 94 CDS etc). This content synchronization is out-of-scope for this 95 document. 97 1.2. Notation 99 Short definitions of expressions used in this document 101 signer An entity signing a zone 103 multi-signer group A group of signers that sign the same zone 105 1.3. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 2. Use Cases 113 2.1. Running a multi-signer setup 115 As described in [RFC8901] a multi-signer DNSSEC configuration has 116 some challenges that can be overcome with the right infrastructure 117 and following a number of steps for setup and operation. 119 In this document we describe how all of the steps in the multi-signer 120 DNSSEC setup can be automated. That is, all except the initial trust 121 between involved signers. 123 2.2. Secure change of name server operator 125 Changing the name server operator of a DNSSEC signed zone can be 126 quite a challenge. Currently the most common method is temporarily 127 "going insecure". This is a bad choice for security, and a bad 128 choice for users relying on the security of the zone. 130 Changing name server operators can be considered to be a transient 131 special case of multi-signer DNSSEC operations. A new operator joins 132 the old operator in a temporary multi-signer setup. Once that is 133 completed, the old operator leaves the multi-signer setup. 135 3. Algorithm 136 3.1. Setting up a new multi-signer group 138 The zone is already authoritatively served by one DNS operator and is 139 DNSSEC signed. For full automation both the KSK and ZSK or CSK must 140 be online. 142 This would be a special case, a multi-signer group with only one 143 signer. 145 3.2. Configuration 147 The following configuration has to be made for any signer of the 148 multi-signer group before joining the group. These steps are not 149 automated by this draft. 151 1. The signers own keys (the keys the signer has the private part 152 of) 154 2. The NS records in the zone 156 3. An established trust to the multi-signer group 158 3.3. A new signer joins the multi-signer group 160 3.3.1. Prerequisites 162 The new signer 164 1. has a working setup of the zone, including DNSSEC signing. 166 2. uses the same algorithm for DNSSEC signing as the multi-signer 167 group uses. 169 3.3.2. Steps for joining 171 1. a new signer joins the group 173 2. Exchange of keys, after this step all signers must have the 174 DNSKEY set of all other signers of the group 176 3. Calculate CDS/CDNSKEY set 178 4. All signers put the ZSK of all other signers in their DNSKEY 179 set. 181 5. All signers publish their CDS/CDNSKEY set 183 6. Wait for parent to pick up DS updates 184 7. Remove CDS/CDNSKEY set from all signers 186 8. Wait 2 time maximum TTL of DS at parent and DNSKEY at all 187 children 189 9. Exchange of NS set, after this step all signers must have the NS 190 set of all other signers 192 10. Compile new complete NS set with NS records from all signers 194 11. Compare to NS set at parent 196 12. If parent is different, publish CSYNC record with NS and A and 197 AAAA bit set. 199 13. Wait for parent to pick up changes 201 14. Remove CSYNC record from all signers 203 3.4. A signer leaves the multi-signer group 205 1. Signal to all other signers to remove the leaving signer's NS 206 records 208 2. Compile new complete NS set with NS records from all signers 210 3. Compare to NS set at parent 212 4. If parent if different, publish CSYNC record with NS and A and 213 AAAA bit set. 215 5. Wait for parent to pick up changes 217 6. Remove CSYNC record from all signers 219 7. Wait 2 times TTL of maximum NS TTL from parent and all signers 221 8. Signal all other signers leaving of multi-signer group 223 9. Stop answering queries 225 10. Remaining signers remove ZSK of leaving signer from their DNSKEY 226 set 228 11. Remaining signers recalculate DNSKEY set 230 12. Calculate CDS/CDNSKEY set 231 13. All signers put the ZSK of all other signers in their DNSKEY 232 set. 234 14. All signers publish their CDS/CDNSKEY set 236 15. Wait for parent to pick up DS updates 238 16. Remove CDS/CDNSKEY set from all signers 240 4. Automation 242 Automation of the necessary steps described in the last section can 243 be divided into two main models, centralized and decentralized. Both 244 have pros and cons and any zone operator should chose wisely. 246 4.1. Centralized 248 In a centralized model the zone operator will run software that 249 executes all steps necessary and controls all signers. 251 4.2. Decentralized 253 In the decentralized models all signers will communicate with each 254 other and execute the necessary steps on their instance only. For 255 this signers need a specialized protocol to communicate configuration 256 details that are not part of the zone data. 258 5. Acknowledgements 260 6. IANA Considerations 262 7. Security Considerations 264 8. Normative References 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, 268 DOI 10.17487/RFC2119, March 1997, 269 . 271 [RFC7477] Hardaker, W., "Child-to-Parent Synchronization in DNS", 272 RFC 7477, DOI 10.17487/RFC7477, March 2015, 273 . 275 [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from 276 the Parent via CDS/CDNSKEY", RFC 8078, 277 DOI 10.17487/RFC8078, March 2017, 278 . 280 9. Informative References 282 [RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D. 283 Blacka, "Multi-Signer DNSSEC Models", RFC 8901, 284 DOI 10.17487/RFC8901, September 2020, 285 . 287 Authors' Addresses 289 Ulrich Wisser 290 The Swedish Internet Foundation 291 Box 92073 292 SE-12007 Stockholm 293 Sweden 295 Email: ulrich@wisser.se 296 URI: https://www.internetstiftelsen.se 298 Shumon Huque 299 Salesforce 300 415 Mission Street, 3rd Floor 301 San Francisco, CA 94105 302 United States of America 304 Email: shuque@gmail.com