idnits 2.17.1 draft-ietf-dnsop-maintain-ds-02.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 (April 4, 2016) is 2943 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: October 6, 2016 Red Hat 6 April 4, 2016 8 Managing DS records from parent via CDS/CDNSKEY 9 draft-ietf-dnsop-maintain-ds-02 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 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 this DNSSEC 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 October 6, 2016. 46 Copyright Notice 48 Copyright (c) 2016 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 a DS Record . . . . . . . . . . . . . . . . . . 3 65 1.2. Introducing a DS record . . . . . . . . . . . . . . . . . 3 66 1.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. The Three Uses of CDS . . . . . . . . . . . . . . . . . . . . 4 69 2.1. The meaning of the CDS RRset . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 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 one method to maintain delegations that can be used 88 when the DNS operator has no other way to inform the parent that 89 changes are needed. [RFC7344] contains no "delete" signal for the 90 child to tell the parent that it wants to remove the DNSSEC security 91 for its domain. 93 [RFC7344] did not include a method for the Initial Trust 94 establishment and left it to each parent to come up with an 95 acceptance policy. 97 1.1. Removing a DS Record 99 This document introduces the delete option for both CDS and CDNSKEY, 100 allowing a child to signal to the parent to turn off DNSSEC. When a 101 domain is moved from one DNS operator to another one, sometimes it is 102 necessary to turn off DNSSEC to facilitate the change of DNS 103 operator. Common scenarios include: 105 1 alternative to doing a proper DNSSEC algorithm rollover due to 106 operational limitations such as software limitations. 108 2 moving from a DNSSEC operator to a non-DNSSEC capable operator. 110 3 moving to an operator that cannot/does-not-want to do a proper 111 DNSSEC rollover. 113 4 when moving between two DNS operators that use disjoint sets of 114 algorithms to sign the zone, thus an algorithm rollover can not be 115 performed. 117 5 the domain holder no longer wants DNSSEC enabled. 119 The lack of a "remove my DNSSEC" option is cited as a reason why some 120 operators cannot deploy DNSSEC, as this is seen as an operational 121 risk. 123 Turning off DNSSEC reduces the security of the domain and thus should 124 only be done carefully, and that decision should be fully under the 125 child domain's control. 127 1.2. Introducing a DS record 129 The converse issue is how a child domain instructs the parent that it 130 wants to have a DS record added. This problem can be solved using a 131 few simplifying assumptions. This document makes the assumption that 132 there are reasonable policies that can be applied and will allow 133 automation of trust introduction. 135 Not being able to enable trust via an easily automated mechanism is 136 hindering DNSSEC at scale for DNS hosters that do not have automated 137 access to the "registry" of the child zone's parent. 139 1.3. Notation 141 When this document uses the word CDS it implies that the same applies 142 to CDNSKEY and vice versa. The only difference between the two 143 records is how information is represented. 145 We use RRR to mean Registry Registrar Registrant in the context of 146 DNS domain markets. 148 When the document uses the word "parent" it implies an entity that is 149 authorized to insert DS records into the parent zone on behalf of the 150 child domain. Which entity this exactly is does not matter. It 151 could be the Registrar or Reseller that the child domain was 152 purchased from. It could be the Registry that the domain is 153 registered in when allowed. It could be some other entity when the 154 RRR framework is not used. 156 1.4. Terminology 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. 162 2. The Three Uses of CDS 164 In general there are three operations that a domain wants to 165 influence on its parent: 167 1 Roll over KSK, this means updating the DS records in the parent to 168 reflect the new set of KSK's at the child. This could be an ADD 169 operation, a DELETE operation on one or more records while keeping 170 at least one DS RR, or a full REPLACE operation. 172 2 Turn off DNSSEC validation, i.e. delete all the DS records. 174 3 Enable DNSSEC validation, i.e. place an initial DS RRset in the 175 parent. 177 Operation 1 is covered in [RFC7344], operations 2 and 3 are defined 178 in this document. In many people's minds, those two later operations 179 carry more risk than the first one. This document argues that 2 is 180 identical to 1 and the third one is different (but not that 181 different). 183 2.1. The meaning of the CDS RRset 185 The semantic meaning of publishing a CDS RRset is interpreted to 186 mean: 188 "Publishing a CDS or CDNSKEY record signals to the parent that the 189 child desires that the corresponding DS records be synchronized. 190 Every parent or parental agent should have an acceptance policy of 191 these records for the three different use cases involved: Initial DS 192 publication, Key rollover, and Returning to Insecure." 194 In short, the CDS RRset is an instruction to the parent to modify the 195 DS RRset if the CDS and DS RRsets differ. The acceptance policy for 196 CDS in the rollover case is "seeing" according to [RFC7344]. The 197 acceptance policy in the Delete case is seeing a (validly signed) CDS 198 RRset with the delete operation specified in this document. 200 3. Enabling DNSSEC via CDS/CDNSKEY 202 There are number of different models for managing initial trust, but 203 in the general case, the child wants to enable global validation for 204 the future. Thus during the period from the time the child publishes 205 the CDS until the corresponding DS is published at the parent is the 206 period that DNS answers for the child could be forged. The goal is 207 to keep this period as short as possible. 209 One important case is how a third party DNS operator can upload its 210 DNSSEC information to the parent, so the parent can publish a DS 211 record for the child. In this case there is a possibility of setting 212 up some kind of authentication mechanism and submission mechanism 213 that is outside the scope of this document. 215 Below are some policies that parents can use. These policies assume 216 that the notifications can be verified or authenticated. 218 3.1. Accept policy via authenticated channel 220 In this case the parent is notified via UI/API that a CDS RRset 221 exists. The parent retrieves the CDS and inserts the corresponding 222 DS RRset as requested, provided that the request comes over an 223 authenticated channel. 225 3.2. Accept with extra checks 227 In this case the parent checks that the source of the notification is 228 allowed to request the DS insertion. The checks could include 229 whether this is a trusted entity, whether the nameservers correspond 230 to the requestor, whether there have been any changes in registration 231 in the last few days, etc. The parent can also send a notification 232 requesting a confirmation. 234 The end result is that the CDS RRset is accepted at the end of the 235 checks or when the out-of-band confirmation is received. 237 3.3. Accept after delay 239 In this case, if the parent deems the request valid, it starts 240 monitoring the CDS RRset at the child nameservers over period of time 241 to make sure nothing changes. After some time or after a number of 242 checks, preferably from different vantage points in the network, the 243 parent accepts the CDS RRset as a valid signal to update its DS RRset 244 for this child. 246 3.4. Accept with challenge 248 In this case the parent instructs the requestor to insert some record 249 into the child domain to prove it has the ability to do so (i.e., it 250 is the operator of the zone). 252 4. DNSSEC Delete Algorithm 254 The DNSKEY algorithm registry contains two reserved values: 0 and 255 255[RFC4034]. The CERT record [RFC4398] defines the value 0 to mean 256 the algorithm in the CERT record is not defined in DNSSEC. 258 [rfc-editor remove before publication] For this reason, using the 259 value 0 in CDS/CDNSKEY delete operations is potentially problematic, 260 but we propose it here anyway as the risk is minimal. The 261 alternative is to reserve a DNSSEC algorithm number for this purpose. 262 [rfc-editor end remove] 264 Right now, no DNSSEC validator understands algorithm 0 as a valid 265 signature algorithm. If a validator sees a DNSKEY or DS record with 266 this algorithm value, it MUST treat it as unknown. Accordingly, the 267 zone is treated as unsigned unless there are other algorithms 268 present. 270 In the context of CDS and CDNSKEY records, DNSSEC algorithm 0 is 271 defined to mean that the entire DS RRset MUST be removed. The 272 contents of the CDS or CDNSKEY RRset MUST contain one RR and only 273 contain the fixed fields as shown below. 275 1 CDS 0 0 0 277 2 CDNSKEY 0 3 0 278 The keying material payload is represented by a single 0. This 279 record is signed in the same way as regular CDS/CDNSKEY RRsets are 280 signed. 282 Strictly speaking the CDS record could be "CDS X 0 X" as only the 283 DNSKEY algorithm is what signals the DELETE operation, but for 284 clarity the "0 0 0" notation is mandated - this is not a definition 285 of DS Digest algorithm 0. The same argument applies to "CDNSKEY 0 3 286 0", the value 3 in second field is mandated by RFC4034 section 2.1.2. 288 Once the parent has verified the CDS/CDNSKEY RRset and it has passed 289 other acceptance tests, the parent MUST remove the DS RRset. After 290 waiting a sufficient amount of time - depending on the parental TTLs 291 - the child can start the process of turning off DNSSEC. 293 5. Security considerations 295 This document's main goal is to avoid validation failures when a 296 domain moves from one DNS operator to another. Turning off DNSSEC 297 reduces the security of the domain and thus should only be done as a 298 last resort. 300 In most cases it is preferable that operators collaborate on the 301 rollover by doing a KSK+ZSK rollover as part of the hand-off, but 302 that is not always possible. This document addresses the case where 303 unsigned state is needed to complete a rollover. 305 Users SHOULD keep in mind that re-establishing trust in delegation 306 can be hard and takes a long time. Before deciding to complete the 307 rollover via an unsigned state, all options SHOULD be considered. 309 A parent SHOULD ensure that when it is allowing a child to become 310 securely delegated, that it has a reasonable assurance that the CDS/ 311 CDNSKEY RRset that is used to bootstrap the security is visible from 312 a geographically and topologically diverse view. It SHOULD also 313 ensure that the zone validates correctly if the parent publishes the 314 DS record. A parent zone might also consider sending an email to its 315 contact addresses to give the child zone a warning that security will 316 be enabled after a certain about of wait time - thus allowing a child 317 administrator to cancel the request. 319 6. IANA considerations 321 This document updates the following IANA registries: "DNS Security 322 Algorithm Numbers" 324 Algorithm 0 adds a reference to this document. 326 7. References 328 7.1. Normative References 330 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 331 Rose, "Resource Records for the DNS Security Extensions", 332 RFC 4034, DOI 10.17487/RFC4034, March 2005, 333 . 335 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 336 DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 337 10.17487/RFC7344, September 2014, 338 . 340 7.2. Informative References 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 344 RFC2119, March 1997, 345 . 347 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 348 System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006, 349 . 351 Appendix A. Acknowledgements 353 This document is generated using the mmark tool that Miek Gieben has 354 developed. 356 Authors' Addresses 358 Olafur Gudmundsson 359 CloudFlare 361 Email: olafur+ietf@cloudflare.com 363 Paul Wouters 364 Red Hat 366 Email: pwouters@redhat.com