idnits 2.17.1 draft-ietf-dnssec-rollover-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-dnssec-rollover-00.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-rollover-00.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-rollover-00.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-dnssec-rollover-00.txt,', but the file name used is 'draft-ietf-dnssec-rollover-00' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 155: '... This response MUST be sent to the o...' RFC 2119 keyword, line 159: '... This response MUST be sent to the o...' RFC 2119 keyword, line 162: '... it MUST, once it has calculated the...' RFC 2119 keyword, line 175: '...ROLLOVER command MUST NOT actually upd...' RFC 2119 keyword, line 203: '... but SHOULD only do so if the corres...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (April 1999) is 9142 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: 11 errors (**), 1 flaw (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT DNSSEC Key Rollover 2 October 1998 3 Expires April 1999 5 Domain Name System (DNS) Security Key Rollover 6 ------ ---- ------ ----- -------- --- -------- 8 Donald E. Eastlake 3rd, Mark Andrews 10 Status of This Document 12 This draft, file name draft-ietf-dnssec-rollover-00.txt, is intended 13 to be become a Proposed Standard RFC. Distribution of this document 14 is unlimited. Comments should be sent to the DNS security mailing 15 list or to the authors. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months. Internet-Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet- 25 Drafts as reference material or to cite them other than as a 26 ``working draft'' or ``work in progress.'' 28 To view the entire list of current Internet-Drafts, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 31 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 32 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 34 Abstract 36 Practical deployment of Domain Name System (DNS) security with good 37 cryptologic practice will involve large volumes of key rollover 38 traffic. A standard format and protocol for such messages is 39 specified. 41 Table of Contents 43 Status of This Document....................................1 44 Abstract...................................................1 46 Table of Contents..........................................2 48 1. Introduction............................................3 49 2. Key Rollover Scenarios..................................3 50 3. Rollover Operation......................................4 51 3.1 Rollover to Parent.....................................4 52 3.2 Rollover to Children...................................5 53 4. Rollover NOTIFY.........................................6 54 5. Security Considerations.................................7 56 References.................................................8 57 Authors Address............................................8 58 Expiration and File Name...................................9 60 1. Introduction 62 The Domain Name System (DNS) [RFC 1034, RFC 1035] is the global 63 hierarchical replicated distributed database system for Internet 64 addressing, mail proxy, and other information. The DNS has been 65 extended to include digital signatures and cryptographic keys as 66 described in [draft-ietf-dnssec-secext2-*]. 68 The principle security service provided for DNS data is data origin 69 authentication. The owner of each zone signs the data in that zone 70 with a private key known only to the zone owner. Anyone that knows 71 the corresponding public key can then authenticate that zone data is 72 from the zone owner. To avoid having to preconfigure resolvers with 73 all zone's public keys, keys are stored in the DNS with each zone's 74 key signed by its parent (if the parent is secure). 76 To obtain high levels of security, keys must be periodically changed, 77 or "rolled over". The longer a private key is used, the more likely 78 it is to be compromised due to cryptanalysis, accident, or treachery 79 [draft-ietf-dnssec-secops-*.txt]. 81 In a widely deployed DNS security system, the volume of update 82 traffic will be large. Just consider the .com zone. If only 10% of 83 its children are secure and change their keys only once a year, you 84 are talking about hundreds of thousands of new child public keys that 85 must be securely sent to the .com manager to sign and return with 86 their new parent signature. And when .com rolls over its private 87 key, it will needs to send hundreds of thousands of new signatures on 88 the existing child public keys to the child zones. 90 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" 91 in this document are to be interpreted as described in RFC 2119. 93 2. Key Rollover Scenarios 95 Although DNSSEC provides for the storage of other keys in the DNS for 96 a variety of purposes, DNSSEC zone keys are included solely for the 97 purpose of being retrieved to authenticate DNSSEC signatures. Thus, 98 when a zone key is being rolled over, the old public key should be 99 left in the zone, along with the addition of the new public key, for 100 as long as it will reasonably be needed to authenticate old 101 signatures that have been cached or are held by applications. If 102 DNSSEC were universally deployed and all DNS server's clocks were 103 synchronized and zone transfers were instantaneous etc., it might be 104 possible to avoid ever having duplicate old/new KEY RRsets but they 105 will be necessary in practical cases. Security aware DNS servers 106 decrease the TTL of secure RRs served as the expiration of their 107 authenticating SIG(s) approaches but some dithered fudge must 108 generally be left due to clock skew and to avoid massive load on 109 large zones due to the signatures on their entire contents expiring 110 simultaneously. 112 Assume a zone with a secure parent and secure children wishes to role 113 over its KEY RRset. This RRset would probably be one KEY RR per 114 crypto algorithm used to secure the zone, but for this scenario, we 115 will simply assume it is one KEY RR. The old KEY RR and two SIG RRs 116 will exist at the apex of the zone and these RRs may also exist at 117 the leaf node for this zone in its parent. The contents of the zone 118 and the zone KEY RRs of its secure children will have SIGs under the 119 old key. 121 The zone owner needs to communicate with its parent to obtain a new 122 parental signature covering both the old and new KEY RRs and covering 123 just the new KEY RR. It would probably want to obtain these in 124 advance so that it can install them at the right time along with its 125 new SIG RRs covering the content of the zone. Finally, it needs to 126 give new SIG RRs to its children that cover their KEY RRs if it has 127 these, or signal its children to ask for such SIG RRs. 129 3. Rollover Operation 131 Rollover operations use a DNS request syntactically identical to the 132 UPDATE request [RFC 2136] except that the operation is ROLLOVER which 133 is equal to TBD. Considerations for such request to the parent and 134 children of a zone are given in the subsections. 136 [This draft does not currently consider cross-certification key 137 rollover.] 139 3.1 Rollover to Parent 141 A zone rolling over its KEY RRset sends a ROLLOVER command to the 142 parent. The Zone should be specified as the parent zone and no 143 Prerequisites are included. The Update section has the KEY RRset on 144 which the parent signature is requested along with the requesting 145 zone's SIG(s) under its old KEY(s) as RRs to be added to the parent 146 zone. The inception and expiration times in this SIG are the 147 requested inception and expiration times for the parent SIG. 149 If the ROLLOVER command is erroneous or violates parental policy, an 150 Error response is returned. 152 If the ROLLOVER command is OK and the parent can sign online, its 153 response may include the new parent SIG(s) in the Update section. 155 This response MUST be sent to the originator of the request. 157 If the parent can not sign online, it should return a response with 158 an empty Update section and queue the SIG(s) calculation request. 159 This response MUST be sent to the originator of the request. 161 Regardless of whether the server has sent the new signatures above, 162 it MUST, once it has calculated the new SIG(s), send a ROLLOVER to 163 the child zone using the DNS port (53) and the server selection 164 algorithm defined in RFC 2136, Section 4. This ROLLOVER reqeust 165 contains the KEY RRset that triggered it and the new SIG(s). This 166 downward ROLLOVER request is distinguished from those in Section 3.2 167 below in that the Zone section is the parental zone. 169 The reason for sending the ROLLOVER request regardless of whether the 170 new SIG RR(s) were sent in the original response is to provide an 171 indication to the operators of the zone in the event someone is 172 trying to hijack the zone. 174 Although the parent zone need not hold or serve the child's key, the 175 ROLLOVER command MUST NOT actually update the parent zone. A later 176 UPDATE command can be used to actually put the new KEY into the 177 parent zone if desired and supported by parent policy. 179 This document does not cover the question of parental policy on key 180 rollovers. Parents may have restrictions on how far into the future 181 they will sign KEY RRsets, what algorithms or key lengths they will 182 support, might require payment for the service, etc. The signing of 183 a future KEY by a parent is, to some extent a granting to the 184 controller of the child private key of future authoritative existence 185 even if the child zone ownership should change. The only effective 186 way of invalidating such future signed child public keys would be for 187 the parent to roll over its key(s), which might be an expensive 188 operation. 190 3.2 Rollover to Children 192 When a zone is going to rollover its key(s), it needs to re-sign the 193 zone keys of any secure children under its new key(s). 195 If the parent holds the KEY RRset for the child (whether or not it 196 actually serves it from the parent zone), it can simply do a ROLLOVER 197 request to to child specifying the child as the Zone in the request 198 and the new SIG(KEY)s to be added in the Update section. The 199 inception and expiration times in the SIG(s) indicate the time during 200 which the parent will be utilizing the new parent key. It is up to 201 the child when and how it adds the new parental SIG(s). The ROLLOVER 202 request may optionally indicate the deletion of old parental SIG(s) 203 but SHOULD only do so if the corresponding key is being withdrawn by 204 the parent in advance of the expiration time in the old SIG(s). It 205 is up to the child when and how it deletes the old parental SIG(s). 206 Even if the expiration of the old SIG(s) equals the inception time of 207 the new SIG(s), the child should serve both signatures for a fudge 208 time to account for clock skew. 210 A ROLLOVER request is used instead of an UPDATE because serves may 211 wish to support ROLLOVER via special techniques, such as notification 212 to the operator, even when they have not implemented UPDATE. With 213 adequate advance notice, even manual cut and paste editing of the 214 master file and restarting of a DNS server process could work. 216 If the parent does not retain knowledge of the child KEY RRset, then 217 the parent simply notifies the child via a ROLLOVER NOTIFY (see 218 Section 4 below) that the parent KEY(s) have changed. The child then 219 proceeds to do an upward ROLLOVER request to obtain the new parental 220 SIG(s). (This requires that a different method, such as TSIG, be 221 used to secure such ROLLOVER requests since we are assuming the 222 parent does not have authoritative knowledge of the child public key. 223 See Section 5 below.) 225 The NOTIFY technique MAY also be used by parents who retain knowledge 226 of their children's KEY RRsets. 228 4. Rollover NOTIFY 230 A ROLLOVER NOTIFY informs a child zone that the parent zone want it 231 to resubmit its keys for resigning. 233 A ROLLOVER NOTIFY MUST be signed and if not signed a BADAUTH response 234 generated. 236 A ROLLOVER NOTIFY is a NOTIFY reqeust [RFC 1996] that has a QTYPE of 237 SIG and the owner name of the child zone. The answer section is 238 empty. 240 The ROLLOVER NOTIFY can be sent to any of the nameservers for the 241 child using the nameserver selection algorithm defined in RFC 2136, 242 Section 4. 244 Nameservers for the child zone receiving a ROLLOVER NOTIFY query will 245 forward the ROLLOVER NOTIFY in the saem manner as an UPDATE is 246 forwarded. 248 Unless the master server is configured to initiate an automatic 249 ROLLOVER it MUST seek to inform its operators that a ROLLOVER NOTIFY 250 request has been received. This could be done by a number of methods 251 including generating a log message, generating an email request to 252 the child zone's SOA RNAME or any other method defined in the 253 server's configuration for the zone. The default should be to send 254 mail to the zone's SOA RNAME. Care should be taken to rate limit 255 these message so prevent them being used to facilitate a denial of 256 service attack. 258 Once the message has been sent (or suppressed) to the child zone's 259 administrator the master server for the child zone is free to respond 260 to the ROLLOVER NOTIFY request. 262 5. Security Considerations 264 The security of ROLLOVER or UPDATE requests is essential, otherwise 265 false children could steal parental authorization or a false parent 266 could cause a child to install an invalid signature on its zone key, 267 etc. 269 A ROLLOVER request can be authentication by request SIG(s)under the 270 old zone KEY(s) of the requestor [draft-ietf-dnssec-secext2-*.txt]. 271 The response SHOULD have transaction SIG(s) under the old zone KEY(s) 272 of the responder. (This public key security could be used to 273 rollover a zone to the unsecured state but at that point it would 274 generally not be possible to roll back without manual intervention.) 276 Alternatively, if there is a prior arrangement between a child and a 277 parent, ROLLOVER requests and responses can be secured and 278 authenticated using TSIG [draft-ietf-dnssec-tsig-*.txt]. (TSIG 279 security could be used to rollover a zone to unsecured and to 280 rollover an unsecured zone to the secured state.) 282 A server that implements online signing SHOULD have the ability to 283 black list a zone and force manual processing or demand that a 284 particular signature be used to generate the ROLLOVER request. This 285 it to allow ROLLOVER to be used even after a private key has been 286 compromised. 288 References 290 [RFC 1034] - P. Mockapetris, "Domain names - concepts and 291 facilities", 11/01/1987. 293 [RFC 1035] - P. Mockapetris, "Domain names - implementation and 294 specification", 11/01/1987. 296 [RFC 1996] - P. Vixie, "A Mechanism for Prompt Notification of Zone 297 Changes (DNS NOTIFY)", August 1996. 299 [RFC 2136] - Dynamic Updates in the Domain Name System (DNS UPDATE). 300 P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997. 302 [draft-ietf-dnsind-tsig-*.txt] 304 [draft-ietf-dnssec-update2-*.txt] 306 [draft-ietf-dnssec-secext2-*.txt] 308 [draft-ietf-dnssec-secops-*.txt] 310 Authors Address 312 Donald E. Eastlake 3rd 313 IBM 314 318 Acton Street 315 Carlisle, MA 01741 USA 317 Telephone: +1 978-287-4877 318 +1 914-784-7913 319 FAX: +1 978-371-7148 320 EMail: dee3@us.ibm.com 322 Mark Andrews 323 Internet Software Consortium 324 1 Seymour Street 325 Dundas Valley, NSW 2117 326 AUSTRALIA 328 Telephone: +61-2-9871-4742 329 Email: marka@isc.org 331 Expiration and File Name 333 This draft expires in April 1999. 335 Its file name is draft-ietf-dnssec-rollover-00.txt.