idnits 2.17.1 draft-ietf-dnssec-secops-02.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-secops-02.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-secops-02.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-secops-02.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-secops-02.txt,', but the file name used is 'draft-ietf-dnssec-secops-02' == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 122 has weird spacing: '...sed for trans...' == 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 (November 1998) is 9293 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) == Unused Reference: 'RFC 1034' is defined on line 257, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 260, but no explicit reference was found in the text == Unused Reference: 'RFC 1750' is defined on line 263, but no explicit reference was found in the text == Unused Reference: 'RSA FAQ' is defined on line 275, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) ** Obsolete normative reference: RFC 2137 (Obsoleted by RFC 3007) -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA FAQ' Summary: 13 errors (**), 1 flaw (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNS Security Working Group Donald E. Eastlake 3rd 2 INTERNET-DRAFT IBM 3 Expires: May 1999 November 1998 5 DNS Security Operational Considerations 6 --- -------- ----------- -------------- 8 Status of This Document 10 This draft, file name draft-ietf-dnssec-secops-02.txt, is intended to 11 be become a Best Current Practices RFC. An earlier version of some of 12 this material was included in [RFC 2065] but that RFC is obsoleted by 13 [draft-ietf-dnssec-secext2-*.txt] which does not include this 14 material. Distribution of this document is unlimited. Comments 15 should be sent to the DNS Security Working Group mailing list or to the authors. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months. Internet-Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet- 26 Drafts as reference material or to cite them other than as a 27 ``working draft'' or ``work in progress.'' 29 To view the entire list of current Internet-Drafts, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 32 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 33 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 35 [Changes from last draft: update author info, file name, dates; add a 36 paragraph about the problems with exessively short key liftetimes; up 37 recommended RSA key size, drop overly specific root meta-key example] 39 Abstract 41 Secure DNS is based on cryptographic techniques. A necessary part of 42 the strength of these techniques is careful attention to the 43 operational aspects of key and signature generation, lifetime, size, 44 and storage. In addition, special attention must be paid to the 45 security of the high level zones, particularly the root zone. This 46 document discusses these operational aspects for keys and signatures 47 used in connection with the KEY and SIG DNS resource records. 49 Acknowledgments 51 The contributions and suggestions of the following persons (in 52 alphabetic order) are gratefully acknowledged: 54 John Gilmore 55 Olafur Gudmundsson 56 Charlie Kaufman 58 Table of Contents 60 Status of This Document....................................1 62 Abstract...................................................2 63 Acknowledgments............................................2 65 Table of Contents..........................................3 67 1. Introduction............................................4 68 2. Public/Private Key Generation...........................4 69 3. Public/Private Key Lifetimes............................4 70 4. Public/Private Key Size Considerations..................5 71 4.1 RSA Key Sizes..........................................5 72 4.2 DSS Key Sizes..........................................6 73 5. Private Key Storage.....................................6 74 6. High Level Zones, The Root Zone, and The Meta-Root Key..6 75 7. Security Considerations.................................7 77 References.................................................8 79 Author's Address...........................................9 80 Expiration and File Name...................................9 82 1. Introduction 84 This document describes operational considerations for the 85 generation, lifetime, size, and storage of DNS cryptographic keys and 86 signatures for use in the KEY and SIG resource records [draft-ietf- 87 dnssec-secext2-*.txt]. Particular attention is paid to high level 88 zones and the root zone. 90 2. Public/Private Key Generation 92 Careful generation of all keys is a sometimes overlooked but 93 absolutely essential element in any cryptographically secure system. 94 The strongest algorithms used with the longest keys are still of no 95 use if an adversary can guess enough to lower the size of the likely 96 key space so that it can be exhaustively searched. Technical 97 suggestions for the generation of random keys will be found in [RFC 98 1750]. 100 Long term keys are particularly sensitive as they will represent a 101 more valuable target and be subject to attack for a longer time than 102 short period keys. It is strongly recommended that long term key 103 generation occur off-line in a manner isolated from the network via 104 an air gap or, at a minimum, high level secure hardware. 106 3. Public/Private Key Lifetimes 108 No key should be used forever. The longer a key is in use, the 109 greater the probability that it will have been compromised through 110 carelessness, accident, espionage, or cryptanalysis. Furthermore, if 111 key rollover is a rare event, there is an increased risk that, when 112 the time does come to change the key, no one at the site will 113 remember how to do it or operational problems will have developed in 114 the key rollover procedures. 116 While public key lifetime is a matter of local policy, these 117 considerations imply that, unless there are extraordinary 118 circumstances, no long term key should have a lifetime significantly 119 over four years. In fact, a reasonable guideline for long term keys 120 that are kept off-line and carefully guarded is a 13 month lifetime 121 with the intent that they be replaced every year. A reasonable 122 maximum lifetime for keys that are used for transaction security or 123 the like and are kept on line is 36 days with the intent that they be 124 replaced monthly or more often. In many cases, a key lifetime of 125 somewhat over a day may be reasonable. 127 On the other hand, public keys with too short a lifetime can lead to 128 excessive resource consumption in re-signing data and retrieving 129 fresh information because cached information becomes stale. In the 130 Internet environment, almost all public keys should have lifetimes no 131 shorter than three minutes, which is a reasonable estimate of maximum 132 packet delay even in unusual circumstances. 134 4. Public/Private Key Size Considerations 136 There are a number of factors that effect public key size choice for 137 use in the DNS security extension. Unfortunately, these factors 138 usually do not all point in the same direction. Choice of zone key 139 size should generally be made by the zone administrator depending on 140 their local conditions. 142 For most schemes, larger keys are more secure but slower. In 143 addition, larger keys increase the size of the KEY and SIG RRs. This 144 increases the chance of DNS UDP packet overflow and the possible 145 necessity for using higher overhead TCP in responses. 147 4.1 RSA Key Sizes 149 Given a small public exponent, verification (the most common 150 operation) for the MD5/RSA algorithm will vary roughly with the 151 square of the modulus length, signing will vary with the cube of the 152 modulus length, and key generation (the least common operation) will 153 vary with the fourth power of the modulus length. The current best 154 algorithms for factoring a modulus and breaking RSA security vary 155 roughly with the 1.6 power of the modulus itself. Thus going from a 156 640 bit modulus to a 1280 bit modulus only increases the verification 157 time by a factor of 4 but may increase the work factor of breaking 158 the key by over 2^900. 160 The recommended minimum RSA algorithm modulus size is 704 bits which 161 is believed by the author to be secure at this time. But high level 162 zones in the DNS tree may wish to set a higher minimum, perhaps 1000 163 bits, for security reasons. (Since the United States National 164 Security Agency generally permits export of encryption systems using 165 an RSA modulus of up to 512 bits, use of that small a modulus, i.e. 166 n, must be considered weak.) 168 For an RSA key used only to secure data and not to secure other keys, 169 704 bits should be adequate at this time. 171 4.2 DSS Key Sizes 173 DSS keys are probably roughly as strong as an RSA key of the same 174 length but DSS signatures are significantly smaller. 176 5. Private Key Storage 178 It is recommended that, where possible, zone private keys and the 179 zone file master copy be kept and used in off-line, non-network 180 connected, physically secure machines only. Periodically an 181 application can be run to add authentication to a zone by adding SIG 182 and NXT RRs and adding no-key type KEY RRs for subzones/algorithms 183 where a real KEY RR for the subzone with that algorithm is not 184 provided. Then the augmented file can be transferred, perhaps by 185 sneaker-net, to the networked zone primary server machine. 187 The idea is to have a one way information flow to the network to 188 avoid the possibility of tampering from the network. Keeping the 189 zone master file on-line on the network and simply cycling it through 190 an off-line signer does not do this. The on-line version could still 191 be tampered with if the host it resides on is compromised. For 192 maximum security, the master copy of the zone file should be off net 193 and should not be updated based on an unsecured network mediated 194 communication. 196 This is not possible if the zone is to be dynamically updated 197 securely [RFC 2137]. At least a private key capable of updating the 198 SOA and NXT chain must be on line in that case. 200 Secure resolvers must be configured with some trusted on-line public 201 key information (or a secure path to such a resolver) or they will be 202 unable to authenticate. Although on line, this public key 203 information must be protected or it could be altered so that spoofed 204 DNS data would appear authentic. 206 Non-zone private keys, such as host or user keys, generally have to 207 be kept on line to be used for real-time purposes such as DNS 208 transaction security. 210 6. High Level Zones, The Root Zone, and The Meta-Root Key 212 Higher level zones are generally more sensitive than lower level 213 zones. Anyone controlling or breaking the security of a zone thereby 214 obtains authority over all of its subdomains (except in the case of 215 resolvers that have locally configured the public key of a 216 subdomain). Therefore, extra care should be taken with high level 217 zones and strong keys used. 219 The root zone is the most critical of all zones. Someone controlling 220 or compromising the security of the root zone would control the 221 entire DNS name space of all resolvers using that root zone (except 222 in the case of resolvers that have locally configured the public key 223 of a subdomain). Therefore, the utmost care must be taken in the 224 securing of the root zone. The strongest and most carefully handled 225 keys should be used. The root zone private key should always be kept 226 off line. 228 Many resolvers will start at a root server for their access to and 229 authentication of DNS data. Securely updating an enormous population 230 of resolvers around the world will be extremely difficult. Yet the 231 guidelines in section 3 above would imply that the root zone private 232 key be changed annually or more often and if it were staticly 233 configured at all these resolvers, it would have to be updated when 234 changed. 236 To permit relatively frequent change to the root zone key yet 237 minimize exposure of the ultimate key of the DNS tree, there will be 238 a "meta-root" key used very rarely and then only to sign a sequence 239 of regular root key RRsets with overlapping time validity periods 240 that are to be rolled out. The root zone contains the meta-root and 241 current regular root KEY RR(s) signed by SIG RRs under both the 242 meta-root and other root private key(s) themselves. 244 The utmost security in the storage and use of the meta-root key is 245 essential. The exact techniques are precautions to be used are 246 beyond the scope of this document. Because of its special position, 247 it may be best to continue with the same meta-root key for an 248 extended period of time such as ten to fifteen years. 250 7. Security Considerations 252 The entirety of this document is concerned with operational 253 considerations of public/private key pair DNS Security. 255 References 257 [RFC 1034] - P. Mockapetris, "Domain Names - Concepts and 258 Facilities", STD 13, November 1987. 260 [RFC 1035] - P. Mockapetris, "Domain Names - Implementation and 261 Specifications", STD 13, November 1987. 263 [RFC 1750] - D. Eastlake, S. Crocker, and J. Schiller, "Randomness 264 Requirements for Security", December 1994. 266 [RFC 2065] - Donald Eastlake, Charles Kaufman, "Domain Name System 267 Security Extensions", 01/03/1997. 269 [RFC 2137] - Donald Eastlake, "Secure Domain Name System Dynamic 270 Update", 04/21/1997. 272 draft-ietf-dnssec-secext2-*.txt - D. Eastlake, "Domain Name System 273 Security Extensions". 275 [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting. 277 Author's Address 279 Donald E. Eastlake 3rd 280 IBM 281 318 Acton Street 282 Carlisle, MA 01741 USA 284 Telephone: +1 978-287-4877 285 +1 914-784-7913 286 fax: +1 978-371-7148 287 email: dee3@us.ibm.com 289 Expiration and File Name 291 This draft expires May 1999. 293 Its file name is draft-ietf-dnssec-secops-02.txt.