idnits 2.17.1 draft-ietf-dnsop-maintain-ds-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 : ---------------------------------------------------------------------------- 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 (June 10, 2016) is 2870 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: 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: Standards Track P. Wouters 5 Expires: December 12, 2016 Red Hat 6 June 10, 2016 8 Managing DS records from parent via CDS/CDNSKEY 9 draft-ietf-dnsop-maintain-ds-03 11 Abstract 13 RFC7344 specifies how DNS trust can be partially maintained in-band 14 between 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 multiple unrelated parties. Some of these parties, such as 20 the DNS operator, might not even be known by all the organizations 21 involved. The inability to disable DNSSEC via in-band signalling is 22 seen as a problem or liability that prevents some DNSSEC adoption at 23 large scale. This document adds a method for in-band signalling of 24 these DNSSEC status changes. 26 Initial trust is considered in general to be a hard technical 27 problem, this document sets forth reasonable policies that clarify 28 and simplify the initial acceptance policy. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 12, 2016. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Introducing a DS record . . . . . . . . . . . . . . . . . 3 66 1.2. Removing a DS Record . . . . . . . . . . . . . . . . . . 3 67 1.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. The Three Uses of CDS . . . . . . . . . . . . . . . . . . . . 4 70 2.1. The meaning of the CDS RRset . . . . . . . . . . . . . . 5 71 3. Enabling DNSSEC via CDS/CDNSKEY . . . . . . . . . . . . . . . 5 72 3.1. Accept policy via authenticated channel . . . . . . . . . 5 73 3.2. Accept with extra checks . . . . . . . . . . . . . . . . 5 74 3.3. Accept after delay . . . . . . . . . . . . . . . . . . . 6 75 3.4. Accept with challenge . . . . . . . . . . . . . . . . . . 6 76 4. DNSSEC Delete Algorithm . . . . . . . . . . . . . . . . . . . 6 77 5. Security considerations . . . . . . . . . . . . . . . . . . . 7 78 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 79 6.1. Promoting RFC7344 to standards track . . . . . . . . . . 8 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 82 7.2. Informative References . . . . . . . . . . . . . . . . . 8 83 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 86 1. Introduction 88 CDS/CDNSKEY [RFC7344] records are used to signal changes in trust 89 anchors. This is one method to maintain delegations that can be used 90 when the DNS operator has no other way to inform the parent that 91 changes are needed. 93 [RFC7344] is lacking two different options for full automated 94 operation to be possible. Firstly it did not define a method for the 95 Initial Trust establishment and left it to each parent to come up 96 with an acceptance policy. Secondly it did not provide a "delete" 97 signal for the child to tell the parent that it wants to remove the 98 DNSSEC security for its domain. 100 1.1. Introducing a DS record 102 The big issue is how a child domain instructs the parent that it 103 wants to have a DS record added. This problem can be solved using a 104 few simplifying assumptions. This document makes the assumption that 105 there are reasonable policies that can be applied and will allow 106 automation of trust introduction. 108 Not being able to enable trust via an easily automated mechanism is 109 hindering DNSSEC at scale for DNS hosters that do not have automated 110 access to the "registry" of the child zone's parent. 112 1.2. Removing a DS Record 114 This document introduces the delete option for both CDS and CDNSKEY, 115 allowing a child to signal to the parent to turn off DNSSEC. When a 116 domain is moved from one DNS operator to another one, sometimes it is 117 necessary to turn off DNSSEC to facilitate the change of DNS 118 operator. Common scenarios include: 120 1 alternative to doing a proper DNSSEC algorithm rollover due to 121 operational limitations such as software limitations. 123 2 moving from a DNSSEC operator to a non-DNSSEC capable operator. 125 3 moving to an operator that cannot/does-not-want to do a proper 126 DNSSEC rollover. 128 4 when moving between two DNS operators that use disjoint sets of 129 algorithms to sign the zone, thus an algorithm rollover can not be 130 performed. 132 5 the domain holder no longer wants DNSSEC enabled. 134 The lack of a "remove my DNSSEC" option is cited as a reason why some 135 operators cannot deploy DNSSEC, as this is seen as an operational 136 risk. 138 Turning off DNSSEC reduces the security of the domain and thus should 139 only be done carefully, and that decision SHOULD be fully under the 140 child domain's control. 142 1.3. Notation 144 When this document uses the word CDS it implies that the same applies 145 to CDNSKEY and vice verse. The only differences between the two 146 records is how information is represented, and who calculates the DS 147 digiest. 149 We use RRR to mean Registry Registrar Registrant in the context of 150 DNS domain markets. 152 When the document uses the word "parent" it implies an entity that is 153 authorized to insert DS records into the parent zone on behalf of the 154 child domain. Which entity this exactly is does not matter. It 155 could be the Registrar or Reseller that the child domain was 156 purchased from. It could be the Registry that the domain is 157 registered in when allowed. It could be some other entity when the 158 RRR framework is not used. 160 1.4. Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in [RFC2119]. 166 2. The Three Uses of CDS 168 In general there are three operations that a domain wants to 169 influence on its parent: 171 1 Enable DNSSEC validation, i.e. place an initial DS RRset in the 172 parent. 174 2 Roll over KSK, this means updating the DS records in the parent to 175 reflect the new set of KSK's at the child. This could be an ADD 176 operation, a DELETE operation on one or more records while keeping 177 at least one DS RR, or a full REPLACE operation. 179 3 Turn off DNSSEC validation, i.e. delete all the DS records. 181 Operation 2 is covered in [RFC7344], operations 1 and 3 are defined 182 in this document. In many people's minds, those two operations carry 183 more risk than the first one. This document argues that 3 is 184 identical to 2 and the first one is different (but not that 185 different). 187 2.1. The meaning of the CDS RRset 189 The semantic meaning of publishing a CDS RRset is interpreted to 190 mean: 192 "Publishing a CDS or CDNSKEY record signals to the parent that the 193 child desires that the corresponding DS records be synchronized. 194 Every parent or parental agent should have an acceptance policy of 195 these records for the three different use cases involved: Initial DS 196 publication, Key rollover, and Returning to Insecure." 198 In short, the CDS RRset is an instruction to the parent to modify the 199 DS RRset if the CDS and DS Reset's differ. The acceptance policy for 200 CDS in the rollover case is "seeing" according to [RFC7344]. The 201 acceptance policy in the Delete case is seeing a (validly signed) CDS 202 RRset with the delete operation specified in this document. 204 3. Enabling DNSSEC via CDS/CDNSKEY 206 There are number of different models for managing initial trust, but 207 in the general case, the child wants to enable global validation for 208 the future. Thus during the period from the time the child publishes 209 the CDS until the corresponding DS is published at the parent is the 210 period that DNS answers for the child could be forged. The goal is 211 to keep this period as short as possible. 213 One important case is how a third party DNS operator can upload its 214 DNSSEC information to the parent, so the parent can publish a DS 215 record for the child. In this case there is a possibility of setting 216 up some kind of authentication mechanism and submission mechanism 217 that is outside the scope of this document. 219 Below are some policies that parents can use. These policies assume 220 that the notifications can be verified or authenticated. 222 3.1. Accept policy via authenticated channel 224 In this case the parent is notified via authenticated channel UI/API 225 that a CDS/CDNSKEY RRset exists. In the case of a CDS RRset the 226 parent retrieves the CDS and inserts the corresponding DS RRset as 227 requested. In the case of CDNSKEY the parent retrieves the CDNSKEY 228 RRset and calculates the DS record(s). 230 3.2. Accept with extra checks 232 In this case the parent checks that the source of the notification is 233 allowed to request the DS insertion. The checks could include 234 whether this is a trusted entity, whether the nameservers correspond 235 to the requester, whether there have been any changes in registration 236 in the last few days, etc. The parent can also send a notification 237 requesting a confirmation, for example by sending email to the 238 registrant requesting a confirmation. The end result is that the CDS 239 RRset is accepted at the end of the checks or when the out-of-band 240 confirmation is received. 242 3.3. Accept after delay 244 In this case, if the parent deems the request valid, it starts 245 monitoring the CDS RRset at the child nameservers over period of time 246 to make sure nothing changes. After some time or after a number of 247 checks, preferably from different vantage points in the network, the 248 parent accepts the CDS RRset as a valid signal to update its DS RRset 249 for this child. 251 3.4. Accept with challenge 253 In this case the parent instructs the requester to insert some record 254 into the child domain to prove it has the ability to do so (i.e., it 255 is the operator of the zone). 257 4. DNSSEC Delete Algorithm 259 The DNSKEY algorithm registry contains two reserved values: 0 and 260 255[RFC4034]. The CERT record [RFC4398] defines the value 0 to mean 261 the algorithm in the CERT record is not defined in DNSSEC. 263 For this reason, using the value 0 in CDS/CDNSKEY delete operations 264 is potentially problematic, but we propose it here anyway as the risk 265 is minimal. The alternative is to reserve a DNSSEC algorithm number 266 for this purpose. 268 Right now, no DNSSEC validator understands algorithm 0 as a valid 269 signature algorithm. If a validator sees a DNSKEY or DS record with 270 this algorithm value, it MUST treat it as unknown. Accordingly, the 271 zone is treated as unsigned unless there are other algorithms 272 present. In general the value 0 should never be used in the context 273 of DNSKEY and DS records. 275 In the context of CDS and CDNSKEY records, DNSSEC algorithm 0 is 276 defined to mean that the entire DS RRset MUST be removed. The 277 contents of the CDS or CDNSKEY RRset MUST contain one RR and only 278 contain the exactly the fields as shown below. 280 1 CDS 0 0 0 282 2 CDNSKEY 0 3 0 283 The keying material payload is represented by a single 0. This 284 record is signed in the same way as regular CDS/CDNSKEY RRset's are 285 signed. This is a change in format from strict interpretation of 286 [RFC7344] and may cause problems with some deployed software. 288 Strictly speaking the CDS record could be "CDS X 0 X" as only the 289 DNSKEY algorithm is what signals the DELETE operation, but for 290 clarity the "0 0 0" notation is mandated - this is not a definition 291 of DS Digest algorithm 0. The same argument applies to "CDNSKEY 0 3 292 0", the value 3 in second field is mandated by RFC4034 section 2.1.2. 294 Once the parent has verified the CDS/CDNSKEY RRset and it has passed 295 other acceptance tests, the parent MUST remove the DS RRset. After 296 waiting a sufficient amount of time - depending on the parental TTL's 297 - the child can start the process of turning off DNSSEC. 299 5. Security considerations 301 This document's main goal is to avoid validation failures when a 302 domain moves from one DNS operator to another. Turning off DNSSEC 303 reduces the security of the domain and thus should only be done as a 304 last resort. 306 In most cases it is preferable that operators collaborate on the 307 rollover by doing a KSK+ZSK rollover as part of the hand-off, but 308 that is not always possible. This document addresses the case where 309 unsigned state is needed to complete a rollover. 311 Users SHOULD keep in mind that re-establishing trust in delegation 312 can be hard and takes a long time. Before deciding to complete the 313 rollover via an unsigned state, all options SHOULD be considered. 315 A parent SHOULD ensure that when it is allowing a child to become 316 securely delegated, that it has a reasonable assurance that the CDS/ 317 CDNSKEY RRset that is used to bootstrap the security is visible from 318 a geographically and topologically diverse view. It SHOULD also 319 ensure that the zone validates correctly if the parent publishes the 320 DS record. A parent zone might also consider sending an email to its 321 contact addresses to give the child zone a warning that security will 322 be enabled after a certain amount of wait time - thus allowing a 323 child administrator to cancel the request. 325 6. IANA considerations 327 This document updates the following IANA registries: "DNS Security 328 Algorithm Numbers" 330 Algorithm 0 adds a reference to this document. 332 6.1. Promoting RFC7344 to standards track 334 Experience has shown that CDS/CDNSKEY are useful in the deployment of 335 DNSSEC. [RFC7344] was published as Informational, this document 336 elevates RFC7344 to standards track. 338 7. References 340 7.1. Normative References 342 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 343 Rose, "Resource Records for the DNS Security Extensions", 344 RFC 4034, DOI 10.17487/RFC4034, March 2005, 345 . 347 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 348 DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 349 10.17487/RFC7344, September 2014, 350 . 352 7.2. Informative References 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 356 RFC2119, March 1997, 357 . 359 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 360 System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006, 361 . 363 Appendix A. Acknowledgements 365 This document is generated using the mmark tool that Miek Gieben has 366 developed. We thank number of people that have provided feedback and 367 useful comments including Bob Harold, John Levine, Matthijs Mekking, 368 Dan York, Shane Kerr, Jacques Latour. 370 Authors' Addresses 372 Olafur Gudmundsson 373 CloudFlare 375 Email: olafur+ietf@cloudflare.com 376 Paul Wouters 377 Red Hat 379 Email: pwouters@redhat.com