idnits 2.17.1 draft-kumari-ogud-dnsop-cds-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines 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 (February 25, 2013) is 4079 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5734' is defined on line 393, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 template W. Kumari 3 Internet-Draft Google 4 Intended status: Informational O. Gudmundsson 5 Expires: August 27, 2013 Shinkuro Inc. 6 G. Barwood 7 February 25, 2013 9 Automating DNSSEC delegation trust maintenance 10 draft-kumari-ogud-dnsop-cds-01 12 Abstract 14 This document describes a method to allow DNS operators to more 15 easily update DNSSEC Key Signing Keys using DNS as communication 16 channel. This document does not address the initial configuration of 17 trust anchors for a domain. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 27, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 2 55 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. DNS delegations . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. DNSSEC key change process . . . . . . . . . . . . . . . . 4 58 3. CDS Record . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. CDS Resource Record Format . . . . . . . . . . . . . . . . 5 60 3.2. CDS Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2.1. Periodic check by Parental Agent . . . . . . . . . . . 5 62 3.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.3.1. Going unsigned . . . . . . . . . . . . . . . . . . . . 6 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 When a DNS operator first signs their zone they need to communicate 76 their DS record(s) (or DNSKEY(s)) to their parent through some out of 77 band method to complete the chain of trust. In many cases this is a 78 fairly annoying and manual process. Unfortunately, every time the 79 child rolls their KSK (Key Signing Key) key they have to repeat the 80 process, possibly multiple times. As this is a manual process DNS 81 operators often avoid rolling their keys, as they don't want to have 82 to do go through the annoyance of publishing the new DS records at 83 the parent. 85 DNSSEC provides data integrity to information published in DNS, thus 86 DNS publication can be used to automate maintenance of delegation 87 information. This document describes a method to automate 88 publication of subsequent DS records, after the initial one has been 89 published. 91 Readers are expected to be familiar with DNSSEC, including [RFC4033], 92 [RFC4034], [RFC4035], [RFC5011] and [RFC6781]. 94 This document is a compilation of two earlier drafts, draft-barwood- 95 dnsop-ds-publish and draft-wkumari-dnsop-ezkeyroll 97 This document outlines a technique in which the "parent" (frequently 98 registrar / registry) periodically (or upon request) polls its signed 99 children and automatically publish new DS records. To a large extent 100 the procedures this document follows are in [RFC6781] section 4.1.2 102 This technique is in some ways similar to RFC 5011 style rollovers, 103 but for sub-domains DS records, instead of trust anchors 105 1.1. Requirements notation 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 [RFC2119]. 111 2. Background 113 2.1. DNS delegations 115 DNS operation consists of delegations of authority, for each 116 delegation there are (most of the time) two parties the parent and 117 child. 119 The parent publishes a NS set that is authoritative for the existence 120 of the delegation but is hint to the contents of the NS record, as 121 well as DS record that expresses what DNSKEY records are to be 122 trusted to sign the DNSKEY RRset in the child. The NS in parent is 123 unsigned as it is hint, the NS bit in the NSEC/NSEC3 record is the 124 proof that the delegation exists. The DS record on the other hand is 125 signed. 127 The child publishes a signed NS record that as it is authoritative 128 for the contents of the NS set. The child on the other hand can not 129 via current DNS mechanisms express all its desires in which DS 130 records to publish. 132 This document is aimed at the case where there is an organizational 133 separation of the child and parent. In this case there are many 134 different operating situations. A common case is the Registrant/ 135 Registrar/Registry relationship. In this case the parent consists of 136 Registrar and Registry, with different rules on what each can do or 137 not do. To remain operating model neutral we will use the neutral 138 word "Parental Agent" as the entity that uses results of DNS queries 139 to inject delegation changes into the parent zone. The entity that 140 inserts the changes in the the DNS is called "DNS Publisher" 142 In many R/R/R cases the Registrar and Registry communicate via 143 EPP[RFC5730] and use the EPP DNSSEC extension [RFC5910]. 145 The "ICANN TLD case" is a common case and we will expand on that 146 here. The registrant registers a domain though a registrar, who then 147 enters information into a database(s), the DNS information (NS, DS 148 and address records) are placed in a database at the registry, and 149 published in the TLD DNS servers. Frequently registrations and 150 subsequent updates take place via web interfaces. When the 151 registrant wants to change NS or DS information it needs to go access 152 the web interface which may take few minutes and many pages to enter 153 the new information. In the ICANN TLD case the Registry operator is 154 by contract not allowed to change the delegation information without 155 the registrar consent, what this means is all changes MUST flow 156 though the registrar. In the context of ICANN TLD's the "Parental 157 Agent" can be assumed to be an registrar, but in other context the 158 "Parental Agent" can be function of the registry. 160 A further complication is when the DNS Operation is separate from the 161 Registrant. There are two common cases of this, registrar handles 162 the DNS operation and a third party does the DNS operation. In the 163 case of a third party DNS operator the Registrant either needs to 164 relay changes in DNS delegation changes or give the operator access 165 to its registration account. If the Registrar is the DNS operators, 166 life is much easier, as it can inject any delegation changes directly 167 into the Registry data bases. The techniques described below are not 168 needed in the case when Registrar is the DNS operator. To reflect 169 that the Registrant is not always the DNS Operator we will use the 170 word "Child" to describe the party that makes changes in the child 171 zone. 173 In some cases Registries want to receive DNSKEY records instead of DS 174 records from as the registry calculates the DS records itself. That 175 operating model constrains what the child can do to automate 176 maintenance of DS records, as the child can not publish a DS record 177 for a key that is not in its DNSKEY RRset. Similarly the Child can 178 not control what digest algorithms are used. 180 2.2. DNSSEC key change process 182 After an DNS operator first signs its zone, there is a need to 183 interact with the parent via the registration interface to "paste in 184 the zone's DS information". The action of logging in through the 185 registration interface authenticates that the user is authorized to 186 change delegation information published in the parent zone. 188 Eventually the Child may want to publish a new DS record in the 189 parent, either because they are rolling their keys, or because they 190 want to publish a stand-by key DS record. This involves performing 191 the same process -- logging into the registration interfaces, 192 selecting the domain, finding the link to change DNSSEC information, 193 pasting (or typing) their DS record (often in a non-standard format) 194 and clicking submit. In a real world test, on web interface this 195 took 12 steps and approximately 3 minutes). As humans (especially DNS 196 operators :-)) dislike tedious, repetitive steps they avoid rolling 197 their DNSSEC keys to avoid having to perform this. Furthermore as 198 this is manual process with cut and paste operations mistakes will 199 happen. 201 3. CDS Record 203 As the DS record can only be present at the parent some other method 204 is needed to automate the expression of what the parental zone DS 205 records contents ought to be. One possibly is to use flags in DNSKEY 206 record, the SEP bit is an optional bit to indicate that the key is 207 allowed to sign the DNSKEY RRset, and the Parental Agent can 208 calculate DS records based on that. But this fails to meet some 209 operating needs, including the child has no influence what DS digest 210 algorithms are used and DS records can only be published for keys 211 that are in the DNSKEY RRset. 213 The CDS record can be published in the child zone and gives the child 214 full control of what is published for it in the parental zone. 216 3.1. CDS Resource Record Format 218 The wire and presentation format of the CDS ("Child DS") record is 219 identical to the DS record. IANA has allocated RR code 59 for the 220 CDS record. 222 No special processing is performed by authoritative servers or by 223 resolvers, when serving or resolving. CDS unlike a DS resides in the 224 child zone. 226 The CDS record MUST be at the zone apex, and MUST be signed with a 227 key that is represented in the current DNSKEY and DS RRset's. If 228 these conditions are not met the CDS record MUST be ignored. 230 3.2. CDS Behavior 232 The CDS RRset MAY be used by the Parental Agent to update the DS 233 RRset in the parent zone 235 Transfer of the contents of the CDS record can be accomplished in a 236 number of ways. A Parental Agent MAY periodically check the child 237 zone to see if the CDS RRset has changed. The child MAY request that 238 the parent check the CDS set via registration interface, or via some 239 other automated mechanism. 241 If at least one DS and one CDS records exist, the Parental Agent 242 validates and then copies the contents of the CDS RRset and replaces 243 the entire existing DS set with the new one. 245 The Child MUST make sure that the CDS RRset is at all times can be 246 validated using a DNSKEY that is referenced from the current DS set 247 in the parent. This can be accomplished by making sure that at all 248 times during a KEY rollover there are either two DS records or two 249 DNSKEY records with SEP bit published in the DNS. 251 When using CDS to publish its key rollover information it is the 252 child's responsibility to monitor the parent for changes to the DS 253 RRset before performing the next action in the key rollover sequence. 254 What this implies is that the child MUST NOT follow a strict time- 255 line but rather strict sequence of steps with time checks. 257 3.2.1. Periodic check by Parental Agent 259 In this case the Parental Agent will query each child zone that has a 260 DS RRset, looking for CDS RRset 261 If present the Parental Agent MUST validate [[RFC4035]] the CDS RRset 262 with a DNSKEY that is represented in the current DS RRset in parent. 263 The Parental Agent should submit a request to the DNS Publisher to 264 publish the contents of the CDS RR(s) as the new a DS record(s) for 265 that zone. The Parental Agent SHOULD log the date and time when of 266 this action including the signature initiation time on the CDS 267 record. The DNS Publisher should log if possible the source of the 268 update, user interface/CDS etc. 270 The Parental Agent SHOULD NOT check more often than . * TTL on the 271 CDS records. 273 3.3. Usage 275 The Parental Agent SHOULD ensure that old versions of the CDS RRset 276 do not overwrite newer versions, which can occur the parent performs 277 the checks too frequently. In that case when there is a delay 278 updating secondary name servers for the child zone. This MAY be 279 accomplished by checking that the signature inception in the RRSIG 280 for CDS is newer and/or the serial number on the child's SOA is 281 greater. 283 If the CDS RRset does not exist, the parent MUST take no action. 284 Specifically it MUST NOT delete the existing DS RRset. 286 If the child zone loses the secret key(s) for the zone, and needs to 287 reset the parent DS RRset, this can only be accomplished by an out- 288 of-band mechanism not defined here. 290 To mitigate situations where a key signing key has been compromised, 291 the Parental Agent MAY take extra security measures, for example 292 informing ( by email or other methods ) the child zone administrator 293 of the change, or by delaying the acceptance of the new DS RRset for 294 some period of time. However the precise out-of-band measures that a 295 parent zone SHOULD take are outside the scope of this document. 297 3.3.1. Going unsigned 299 In theory the child can use the CDS to reflect the parent to remove 300 the DS records. This can be accomplished by publishing CDS record 301 with the following contents: 303 @ IN CDS 0 0 0 305 This is an suggestion and its security implications have not been 306 fully examined but an RFC11 like process should be used before this 307 is accepted. It is important that the Child remain signed until the 308 DS record has been removed from the parent and has timed out from 309 caches. 311 Note: maybe it is better to register a special DS digest algrithm 312 number for this ? 313 If the child zone does go unsigned, the Parental Agent should not 314 treat that as intent to go unsigned since that could be an attack. 315 An attacker could spoof unsigned responses to queries from the 316 Parental Agent in an attempt to force a break in the DNSSEC chain. 318 4. IANA Considerations 320 IANA has assigned RR Type code 59 for CDS. This was done for an 321 earlier version of this document (draft-barwood-dnsop-ds-publish). 323 5. Security Considerations 325 [ This needs a more work, suggestions welcome.] 327 In the event of a compromise of the server generating signatures for 328 a zone, attacker might be able to generate and publish new CDS 329 records. The modified CDS records, will be picked up by this 330 technique and so may allow the attacker to extend the effective time 331 of his attack. This can be dealt with by contacting the parent 332 (possibly via a registrar web interface) and removing any compromised 333 DS keys. 335 A compromise of the registrar, will not be mitigated by this 336 technique, as the "new registrant" can delete/modify the DS records 338 While it may be tempting, this SHOULD NOT be used for initial 339 enrollment of keys since there is no way to ensure that the initial 340 key is the correct one. If is is used, strict rules for inclusion of 341 keys like hold down times, challenge data inclusion etc., ought to be 342 used. 344 The CDS RR type should allow for enhanced security by simplifying 345 process. Since rollover is automated, updating a DS RRset by other 346 means may be regarded as unusual and subject to extra security 347 checks. 349 6. Acknowledgements 351 This is by no means the invention of the authors. This idea has been 352 floating around for a long time. This simply documents it for 353 discussion. 355 We would like to thank: Joe Abley, Roy Arends, Jim Galvin, Cricket 356 Liu, Stephan Lagerholm, Matt Larson, Olaf Kolkman, Suzanne Woolf, 357 Paul Wouters. 359 There were a large number of other folk with whom we discussed this, 360 apologies for not remembering everyone. 362 7. References 364 7.1. Normative References 366 [IANA.AS_Numbers] 367 IANA, "Autonomous System (AS) Numbers", , . 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, March 1997. 373 7.2. Informative References 375 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. 376 Rose, "DNS Security Introduction and Requirements", RFC 377 4033, March 2005. 379 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D. and S. 380 Rose, "Resource Records for the DNS Security Extensions", 381 RFC 4034, March 2005. 383 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D. and S. 384 Rose, "Protocol Modifications for the DNS Security 385 Extensions", RFC 4035, March 2005. 387 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 388 Trust Anchors", STD 74, RFC 5011, September 2007. 390 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 391 STD 69, RFC 5730, August 2009. 393 [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 394 Transport over TCP", STD 69, RFC 5734, August 2009. 396 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 397 Security Extensions Mapping for the Extensible 398 Provisioning Protocol (EPP)", RFC 5910, May 2010. 400 [RFC6781] Kolkman, O., Mekking, W. and R. Gieben, "DNSSEC 401 Operational Practices, Version 2", RFC 6781, December 402 2012. 404 Appendix A. Changes / Author Notes. 406 [RFC Editor: Please remove this section before publication ] 408 From - to -1. 410 o Removed from section .1: "If a child zone has gone unsigned, i.e. 411 no DNSKEY and no RRSIG in the zone, the parental representative 412 MAY treat that as intent to go unsigned. (NEEDS DISCUSSION)." 413 Added new text at end. -- suggestion by Scott Rose 20/Feb/13. 414 o Added some background on the different DNS Delegation operating 415 situations and how they affect interaction of parties. This moved 416 some blocks of text from later sections into here. 417 o Number of textual improvements from Stephan Lagerholm 418 o Added motivation why CDS is needed in CDS definition section 419 o Unified terminolgy in the document. 420 o Much more background 422 Authors' Addresses 424 Warren Kumari 425 Google 426 1600 Amphitheatre Parkway 427 Mountain View, CA, 94043 428 US 430 Email: warren@kumari.net 432 Olafur Gudmundsson 433 Shinkuro Inc. 434 4922 Fairmont Av, Suite 250 435 Bethesda, MD 20814 436 USA 438 Email: ogud@ogud.com 440 George Barwood 441 33 Sandpiper Close 442 Gloucester, GL2 4LZ 443 United Kingdom 445 Email: warren@kumari.net