idnits 2.17.1 draft-kumari-ogud-dnsop-cds-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 (February 18, 2013) is 4084 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-sidr-iana-objects' is defined on line 287, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 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 22, 2013 Shinkuro Inc. 6 G. Barwood 7 February 18, 2013 9 Easy DNSSEC Key Publish 10 draft-kumari-ogud-dnsop-cds-00 12 Abstract 14 This document describes a method to allow DNS operators to more 15 easily publish updated DNSSEC Key Signing Keys. This document does 16 not address the initial configuration of trust anchors for a domain. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 22, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 54 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. CDS Resource Record Format . . . . . . . . . . . . . . . . . . 4 56 4. CDS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4.1. Periodic check by parental agent . . . . . . . . . . . . . 5 58 5. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5.1. Going unsigned . . . . . . . . . . . . . . . . . . . . . . 6 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 65 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 66 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 When a DNS operator first signs their zone they need to communicate 72 their DS record(s) (or DNSKEY(s)) to their parent through some out of 73 band method. In many cases this is a fairly annoying and manual 74 process. Unfortunately, every time the child rolls their KSK (Key 75 Signing Key) key they have to repeat the process, possibly multiple 76 times. As this is a manual process DNS operators often avoid rolling 77 their keys, as they don't want to have to do go through the annoyance 78 of publishing the new keys. 80 This document describes a method to automate publication of 81 subsequent DS records, after the initial one has been published. 83 Readers are expected to be familiar with DNSSEC, including [RFC4033], 84 [RFC4034], [RFC4035] and [RFC6781]. 86 This document is a compilation of two earlier drafts, 87 draft-barwood-dnsop-ds-publish and draft-wkumari-dnsop-ezkeyroll 89 This document outlines a technique in which the parent (often 90 registrar / registry) periodically polls its signed children and 91 automatically publish new DS records. To a large extent the 92 procedures this document follows are in [RFC6781] section 4.1.2 94 This technique is in some ways similar to RFC 5011 style rollovers, 95 but for subdomains instead of trust anchors 97 1.1. Requirements notation 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2. Background 105 For ease of explanation, we will mainly describe the "standard" case 106 where a DNS operator registers a domain though a registrar, who then 107 publishes the information in a registry, but this same technique can 108 be used anywhere where a child needs to update their DS resource 109 record. We will also assume that the registrar provides a web 110 interface for adding DS resource record information; in a 111 distressingly large number of cases the registrar doesn't (yet) have 112 this functionality, and so the operator has to communicate their DS 113 to the registrar through email or a telephone call, but the actual 114 mechanism doesn't matter. We will further assume that the registrant 115 is also the DNS operator - this technique is expandable to any 116 relationship, but the background explanation gets more tricky. 118 After an DNS operator first signs its zone, they login to the 119 registrar's web interface and then paste in the zone's DS 120 information. The registrar then communicates the DS record to the 121 registry who publishes it. The action of logging in through the web 122 interface authenticates that the user is authorized to publish in the 123 zone. 125 Eventually the registrant may want to publish a new DS record in the 126 parent, either because they are rolling their keys, or because they 127 want to publish a stand-by key DS record. This involves performing 128 the same process -- logging into a web interfaces, selecting the 129 domain, finding the link to change DNSSEC information, pasting (or 130 typing) their DS record (often in a non-standard format) and clicking 131 submit (in a real world test, this took 12 steps and approximately 3 132 minutes). As humans (especially DNS operators :-)) dislike tedious, 133 repetitive steps they often avoid rolling their DNSSEC keys to avoid 134 having to perform this. 136 3. CDS Resource Record Format 138 The wire and presentation format of the CDS ("Child DS") record is 139 identical to the DS record. IANA has allocated RR code 59 for the 140 CDS record. 142 However no special processing is performed by authoritative servers 143 or by resolvers, when serving or resolving. CDS unlike a DS resides 144 in the child zone. 146 The CDS record MUST be signed with a key that has the Secure Entry 147 Point flag set, just like the DNSKEY record. 149 4. CDS Behavior 151 The CDS RRset MAY be used by the parent (or a parental 152 representative) to update the DS RRset in the parent zone we call 153 this entity "parental agent". 155 In many environments (for example, gTLDs) the parent will be a 156 registry, and is expected to not have direct contact with the child 157 (registrant). In these cases, the registrar (or a contractor for the 158 registrar) will be the one that queries the child zone for the CDS 159 record, and if found, will publish it in the parent (probably using 160 [RFC5734]). It is conceivable that this could be a "value added" 161 service. 163 Transfer of the contents of the CDS record can be accomplished in a 164 number of ways. A parental agent MAY periodically check the child 165 zone to see if the CDS RRset has changed. The child MAY request that 166 the parent check the CDS set via registration interface, or via some 167 other automated mechanism. 169 The child MUST make sure that the CDS RRset is at all times 170 validatable using a DNSKEY that is referenced from the current DS set 171 in the parent. This can be accomplished by making sure that at all 172 times during a KEY rollover there are either two DS records or two 173 DNSKEY records with SEP bit published in the DNS. 175 When using CDS to publish its key rollover information it is the 176 child's responsibility to monitor the parent for changes to the DS 177 RRset before performing the next action in the key rollover sequence. 178 What this implies is that the child MUST NOT follow a strict timeline 179 but rather strict sequence of steps with time checks. 181 4.1. Periodic check by parental agent 183 In this case the parental agent will query each child zone that has a 184 DS RRset, looking for CDS RRset 186 If present the parental agent MUST validate [[RFC4035]] the CDS 187 RRset. If the validation succeeds with a DNSKEY that is represented 188 in the current DS RRset in parent. The parenteral agent should 189 submit a request to the registry to publish the contents of the CDS 190 RR(s) as the new a DS record(s) for that zone. The parental agent 191 SHOULD log the date and time when of this action including the 192 signature initiation time on the CDS record. The registry should log 193 if possible the source of the update, user interface/CDS etc. 195 5. Usage 197 The parent zone SHOULD ensure that old versions of the CDS RRset do 198 not overwrite newer versions, which can occur the parent performs the 199 checks too frequently. In that case when there is a delay updating 200 secondary name servers for the child zone. This MAY be accomplished 201 by checking that the signature inception in the RRSIG for CDS is 202 newer 204 If the CDS RRset does not exist, the parent MUST take no action. 205 Specifically it MUST NOT delete the existing DS RRset. 207 If the child zone loses the secret key(s) for the zone, and needs to 208 reset the parent DS RRset, this must be accomplished by an out-of- 209 band mechanism not defined here. 211 To mitigate situations where a key signing key has been compromised, 212 the parent zone MAY take extra security measures, for example 213 informing ( by email or other methods ) the zone administrator of the 214 change, and delaying the acceptance of the new DS RRset for some 215 period of time. However the precise out-of-band measures that a 216 parent zone SHOULD take are outside the scope of this document. 218 5.1. Going unsigned 220 In theory the child can use the CDS to reflect the parent to remove 221 the DS records. This can be accomplished by publishing CDS record 222 with the following contents: 224 @ IN CDS 0 0 0 226 This is an suggestion and its security implications have not been 227 fully examined but an RFC5011 like process should be used before this 228 is accepted. 230 If a child zone has gone unsigned, i.e. no DNSKEY and no RRsigs in 231 the zone, the parental representative MAY treat that as intent to go 232 unsigned. (NEEDS DISCUSSION). 234 6. IANA Considerations 236 IANA has assigned RR Type code 59 for CDS. This was done for an 237 earlier version of this document (draft-barwood-dnsop-ds-publish). 239 7. Security Considerations 241 [ This needs a more work, suggestions welcome.] 243 In the event of a compromise of the server generating signatures for 244 a zone, attacker may be able to generate and publish new CDS records. 245 These will be picked up by this technique and so may allow the 246 attacker to extend the effective time of his attack. This can be 247 dealt with by contacting the parent (potentially though a registrar 248 web interface) and removing any compromised DS keys. 250 A compromise of the registrar, will not be mitigated by this 251 technique 253 While it may be tempting, this should NOT be used for initial 254 enrolment of keys since there is no way to ensure that the initial 255 key is the correct one. 257 The CDS RRtype should allow for enhanced security by simplifying 258 process. Since rollover is automated, updating a DS RRset by other 259 means may be regarded as unusual and subject to extra security 260 checks. 262 8. Acknowledgements 264 This is by no means the invention of the authors. This idea has been 265 floating around for a long time. This simply documents it for 266 discussion. 268 We would like to thank: Joe Abley, Roy Arends, Jim Galvin, Cricket 269 Liu, Matt Larson, Olaf Kolkman, Suzanne Woolfe. 271 There were a large number of other folk with whom we discussed this, 272 apologies for not remembering everyone. 274 9. References 276 9.1. Normative References 278 [IANA.AS_Numbers] 279 IANA, "Autonomous System (AS) Numbers", 280 . 282 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 283 Requirement Levels", BCP 14, RFC 2119, March 1997. 285 9.2. Informative References 287 [I-D.ietf-sidr-iana-objects] 288 Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects 289 issued by IANA", draft-ietf-sidr-iana-objects-03 (work in 290 progress), May 2011. 292 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 293 Rose, "DNS Security Introduction and Requirements", 294 RFC 4033, March 2005. 296 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 297 Rose, "Resource Records for the DNS Security Extensions", 298 RFC 4034, March 2005. 300 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 301 Rose, "Protocol Modifications for the DNS Security 302 Extensions", RFC 4035, March 2005. 304 [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 305 Transport over TCP", STD 69, RFC 5734, August 2009. 307 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 308 Operational Practices, Version 2", RFC 6781, 309 December 2012. 311 Appendix A. Changes / Author Notes. 313 [RFC Editor: Please remove this section before publication ] 315 From -00 to -01. 317 o Nothing changed in the template! 319 Authors' Addresses 321 Warren Kumari 322 Google 323 1600 Amphitheatre Parkway 324 Mountain View, CA 94043 325 US 327 Email: warren@kumari.net 329 Olafur Gudmundsson 330 Shinkuro Inc. 331 4922 Fairmont Av, Suite 250 332 Bethsda, MD 20814 333 USA 335 Email: ogud@ogud.com 337 George Barwood 338 33 Sandpiper Close 339 Gloucester GL2 4LZ 340 United Kingdom 342 Email: warren@kumari.net