idnits 2.17.1 draft-ietf-dnsop-maintain-ds-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 14, 2015) is 3027 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop O. Gudmundsson 3 Internet-Draft CloudFlare 4 Intended status: Informational P. Wouters 5 Expires: June 16, 2016 Red Hat 6 December 14, 2015 8 Managing DS records from parent via CDS/CDNSKEY 9 draft-ietf-dnsop-maintain-ds-00 11 Abstract 13 RFC7344 specifies how DNS trust can be maintained in-band between 14 parent and child. There are two features missing in that 15 specification: initial trust setup and removal of trust anchor. This 16 document addresses both these omissions. 18 Changing a domain's DNSSEC status can be a complicated matter 19 involving many parties. Some of these parties, such as the DNS 20 operator, might not even be known by all organisations involved. The 21 inability to enable or disable DNSSEC via in-band signalling is seen 22 as a problem or liability that prevents DNSSEC adoption at large 23 scale. This document adds a method for in-band signalling of DNSSEC 24 status changes. 26 Initial trust is considered a much harder problem, this document will 27 seek to clarify and simplify the initial acceptance policy. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on June 16, 2016. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Removing DS . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Introducing DS . . . . . . . . . . . . . . . . . . . . . 3 66 1.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. The Three Uses of CDS . . . . . . . . . . . . . . . . . . . . 4 69 2.1. The meaning of CDS ? . . . . . . . . . . . . . . . . . . 4 70 3. Enabling DNSSEC via CDS/CDNSKEY . . . . . . . . . . . . . . . 5 71 3.1. Accept policy via authenticated channel . . . . . . . . . 5 72 3.2. Accept with extra checks . . . . . . . . . . . . . . . . 5 73 3.3. Accept after delay . . . . . . . . . . . . . . . . . . . 5 74 3.4. Accept with challenge . . . . . . . . . . . . . . . . . . 6 75 4. DNSSEC Delete Algorithm . . . . . . . . . . . . . . . . . . . 6 76 5. Security considerations . . . . . . . . . . . . . . . . . . . 7 77 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 80 7.2. Informative References . . . . . . . . . . . . . . . . . 8 81 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 84 1. Introduction 86 CDS/CDNSKEY [RFC7344] records are used to signal changes in trust 87 anchors, this is a great way to maintain delegations when the DNS 88 operator has no other way to inform the parent that changes are 89 needed. RFC7344 contains no "delete" signal for the child to tell 90 the parent that it wants to change the DNSSEC security of its domain. 92 [RFC7344] punted the Initial Trust establishment question and left it 93 to each parent to come up with an acceptance policy. 95 1.1. Removing DS 97 This document introduces the delete option for both CDS and CDNSKEY. 98 to allow a child to signal the parent to turn off DNSSEC. When a 99 domain is moved from one DNS operator to another one, sometimes it is 100 necessary to turn off DNSSEC to facilitate the change of DNS 101 operator. Common scenarios include: 103 1 moving from a DNSSEC operator to a non-DNSSEC capable one or one 104 that does not support the same algorithms as the old one. 106 2 moving to one that cannot/does-not-want to do a proper DNSSEC 107 rollover. 109 3 the domain holder does not want DNSSEC. 111 4 when moving between two DNS operators that use disjoint sets of 112 algorithms to sign the zone, thus algorithm roll can not be 113 performed. 115 Whatever the reason, the lack of a "remove my DNSSEC" option is 116 turning into the latest excuse as why DNSSEC cannot be deployed. 118 Turing off DNSSEC reduces the security of the domain and thus should 119 only be done carefully, and that decision should be fully under the 120 child domain's control. 122 1.2. Introducing DS 124 The converse issue is how does a child domain instruct the parent it 125 wants to have a DS record added. This problem is not as hard as many 126 have assumed, given a few simplifying assumptions. This document 127 makes the assumption that there are reasonable policies that can be 128 applied and will allow automation of trust introduction. 130 Not being able to enable trust via an easily automated mechanism is 131 hindering DNSSEC at scale by anyone that does not have automated 132 access to its parent's "registry". 134 1.3. Notation 136 When this document uses the word CDS it implies that the same applies 137 to CDNSKEY and vice versa, the only difference between the two 138 records is how information is represented. 140 When the document uses the word "parent" it implies an entity that is 141 authorized to insert into parent zone information about this child 142 domain. Which entity this is exactly does not matter. It could be 143 the Registrar or Reseller that the child domain was purchased from. 144 It could be the Registry that the domain is registered in when 145 allowed. It could be some other entity when the RRR framework is not 146 used. 148 We use RRR to mean Registry Registrar Reseller in the context of DNS 149 domain markets. 151 1.4. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 2. The Three Uses of CDS 159 In general there are three operations that a domain wants to 160 influence on its parent: 162 1 Roll over KSK, this means updating the DS records in the parent to 163 reflect the new set of KSK's at the child. This could be an ADD 164 operation, a Delete operation on one or more records while keeping 165 at least one DS RR, or a full Replace operation 167 2 Turn off DNSSEC validation, i.e. delete all the DS records 169 3 Enable DNSSEC validation, i.e. place initial DS RRset in the 170 parent. 172 Operation 1 is covered in [RFC7344], operations 2 and 3 are defined 173 in this document. In many people's minds, those two later operations 174 carry more risk than the first one. This document argues that 2 is 175 identical to 1 and the final one is different (but not that 176 different). 178 2.1. The meaning of CDS ? 180 The fundamental question is what is the semantic meaning of 181 publishing a CDS RRset in a zone? We offer the following 182 interpretation: 184 "Publishing a CDS or CDNSKEY record signifies to the parent that the 185 child is ready for the corresponding DS records to be synchronized. 186 Every parent or parental agent should have an acceptance policy of 187 these records for the three different use cases involved: Initial DS 188 publication, Key rollover, and Returning to Insecure." 189 In short, the CDS RRset is an instruction to the parent to modify DS 190 RRset if the CDS and DS RRsets differ. The acceptance policy for CDS 191 in the rollover case is "seeing" according to [RFC7344]. The 192 acceptance policy in the Delete case is just seeing a CDS RRset with 193 the delete operation specified in this document. 195 3. Enabling DNSSEC via CDS/CDNSKEY 197 There are number of different models for managing initial trust, but 198 in the general case, the child wants to enable global validation for 199 the future. Thus during the period from the time the child publishes 200 the CDS until the corresponding DS is published is the period that 201 DNS answers for the child could be forged. The goal is to keep this 202 period as short as possible. 204 One important case is how a 3rd party DNS operator can upload its 205 DNSSEC information to the parent, so the parent can publish a DS 206 record for the child. In this case there is a possibility of setting 207 up some kind of authentication mechanism and submission mechanism 208 that is outside the scope of this document. 210 Below are some policies that parents can use. These policies assume 211 that the notifications are can be authenticated and/or identified. 213 3.1. Accept policy via authenticated channel 215 In this case the parent is notified via UI/API that CDS exists, the 216 parent retrieves the CDS and inserts the DS record as requested, if 217 the request comes over an authenticated channel. 219 3.2. Accept with extra checks 221 In this case the parent checks that the source of the notification is 222 allowed to request the DS insertion. The checks could include 223 whether this is a trusted entity, whether the nameservers correspond 224 to the requestor, whether there have been any changes in registration 225 in the last few days, etc, or the parent can send a notification 226 requesting an confirmation. 228 The end result is that the CDS is accepted at the end of the checks 229 or when the out-of-band confirmation is received. 231 3.3. Accept after delay 233 In this case, if the parent deems the request valid, it starts 234 monitoring the CDS records at the child nameservers over period of 235 time to make sure nothing changes. After number of checks, 236 preferably from different vantage points, the parent accepts the CDS 237 records as a valid signal to update. 239 3.4. Accept with challenge 241 In this case the parent instructs the requestor to insert some record 242 into the child domain to prove it has the ability to do so (i.e., it 243 is the operator of the zone). 245 4. DNSSEC Delete Algorithm 247 The DNSKEY algorithm registry contains two reserved values: 0 and 248 255[RFC4034]. The CERT record [RFC4398] defines the value 0 to mean 249 the algorithm in the CERT record is not defined in DNSSEC. 251 [rfc-editor remove before publication] For this reason, using the 252 value 0 in CDS/CDNSKEY delete operations is potentially problematic, 253 but we propose that here anyway as the risk is minimal. The 254 alternative is to reserve one DNSSEC algorithm number for this 255 purpose. [rfc-editor end remove] 257 Right now, no DNSSEC validator understands algorithm 0 as a valid 258 signature algorithm, thus if the validator sees a DNSKEY or DS record 259 with this value, it will treat it as unknown. Accordingly, the zone 260 is treated as unsigned unless there are other algorithms present. 262 In the context of CDS and CDNSKEY records, DNSSEC algorithm 0 is 263 defined and means the entire DS set MUST be removed. The contents of 264 the records MUST contain only the fixed fields as show below. 266 1 CDS 0 0 0 268 2 CDNSKEY 0 3 0 270 There is no keying material payload in the records, just the command 271 to delete all DS records. This record is signed in the same way as 272 CDS/CDNSKEY is signed. 274 Strictly speaking the CDS record could be "CDS X 0 X" as only the 275 DNSKEY algorithm is what signals the delete operation, but for 276 clarity the "0 0 0" notation is mandated, this is not a definition of 277 DS Digest algorithm 0. Same argument applies to "CDNSKEY 0 3 0". 279 Once the parent has verified the CDS/CDNSKEY record and it has passed 280 other acceptance tests, the DS record MUST be removed. At this point 281 the child can start the process of turning DNSSEC off. 283 5. Security considerations 285 This document is about avoiding validation failures when a domain 286 moves from one DNS operator to another one. Turing off DNSSEC 287 reduces the security of the domain and thus should only be done as a 288 last resort. 290 In most cases it is preferable that operators collaborate on the 291 rollover by doing a KSK+ZSK rollover as part of the handoff, but that 292 is not always possible. This document addresses the case where 293 unsigned state is needed. 295 Users SHOULD keep in mind that re-establishing trust in delegation 296 can be hard and take a long time thus before going to unsigned all 297 options SHOULD be considered. 299 A parent should ensure that when it is allowing a child to become 300 securely delegated, that it has a reasonable assurance that the CDS/ 301 CDNSKEY that is used to bootstrap the security on is visible from a 302 geographically and network topology diverse view. It should also 303 ensure the the zone would validate if the parent published the DS 304 record. A parent zone might also consider sending an email to its 305 contact addresses to give the child a warning that security will be 306 enabled after a certain about of wait time - thus allowing a child 307 administrator to cancel the request. 309 This document does not introduce any new problems, but like Negative 310 Trust Anchor[RFC7646], it addresses operational reality. 312 6. IANA considerations 314 This document updates the following IANA registries: "DNS Security 315 Algorithm Numbers" 317 Algorithm 0 adds a reference to this document. 319 7. References 321 7.1. Normative References 323 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 324 Rose, "Resource Records for the DNS Security Extensions", 325 RFC 4034, DOI 10.17487/RFC4034, March 2005, 326 . 328 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 329 DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 330 10.17487/RFC7344, September 2014, 331 . 333 7.2. Informative References 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 337 RFC2119, March 1997, 338 . 340 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 341 System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006, 342 . 344 [RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J., 345 and R. Weber, "Definition and Use of DNSSEC Negative Trust 346 Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015, 347 . 349 Appendix A. Acknowledgements 351 This document is generated using the mmark tool that Miek Gieben has 352 developed. 354 Authors' Addresses 356 Olafur Gudmundsson 357 CloudFlare 359 Email: olafur+ietf@cloudflare.com 361 Paul Wouters 362 Red Hat 364 Email: pwouters@redhat.com