idnits 2.17.1 draft-ietf-dnsop-keyhand-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 1) being 289 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Unrecognized Status in 'Category: I-D', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2, 2001) is 8455 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: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSOP WG Edward Lewis 2 INTERNET DRAFT NAI Labs 3 Category: I-D March 2, 2001 5 Handling of DNS Zone Signing Keys 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Comments should be sent to the authors or the DNSOP WG mailing list 29 dnsop@cafax.se. 31 This draft expires on September 2, 2001 33 Copyright Notice 35 Copyright (C) The Internet Society (1999-2001). All rights reserved. 37 Abstract 39 DNS Security Extensions require a greater interaction between zone 40 administrations sharing a zone cut. The center of the interaction is 41 the handling of the zone keys of the child and the signature applied 42 by the parent. DNSSEC does not include a protocol for this, but the 43 means of this interaction need definition to maintain the security of 44 DNS. 46 1 Introduction 48 This document has existed for quite some time. The purpose of this 49 document is to capture lessons learned regarding DNSSEC zone keys. In 50 the past two years numerous workshops have been held, each adding to 51 the community's lessons learned. 53 In past editions of this document, the outline consisted of describing 54 the lifecycle of a key and the steps needed to get it validated by the 55 parent. In this edition, a new approach is being taken. The lessons 56 learned are described without regard to fitting into an operations 57 procedure. The hope is to develop a better explanation of the issues 58 surrounding what will someday describe a "best current practice." 60 2 Terminology 62 Zone keys are explicitly defined in RFC 2535, but there have been 63 certain phrases that are increasingly used that may cause confusion to 64 new comers. 66 A zone key really refers to two cryptographic values, called a public 67 key and a private key. The two values always work in tandem, hence 68 the singular reference. The phrase "signing with the zone key" refers 69 to using the private key to generate digital signatures. The phrase 70 "verifying with the zone key" refers to the use of the public key to 71 verify the data and signature. 73 3 Threats to Keys 75 The threats to a zone key center on threats to the private key. There 76 are three ways a zone key can be come useless to the owner (and 77 possibly an advantage to an attacker). The private key could be come 78 "exposed," "discovered," or "lost." The latter case, a lost key, 79 refers to perhaps accidentally deleting the key from storage, and is a 80 case that is of little concern. (Keys can be replaced easily.) 82 An "exposed" key refers to a private key that is seen, or copied, by 83 an unauthorized person. This could happen if the host holding the key 84 is infiltrated or sloppy transferring of the key (such as in 85 unencrypted email). 87 A "discovered key" is one that is found through performing 88 cryptographic analysis of the public key, data sets and signatures. 89 Depending on various factors, such as algorithm and key size, a 90 determined analyst can reverse engineer the private key. 92 This latter loss is the most troublesome. This kind of loss is what 93 creates the limited lifetime of a key. Because of this, there is a 94 need to fully develop key changing (or rollover) procedures. 96 Unfortunately, there is no current recommendation on how long it would 97 take to discover a given private key. Such knowledge would be 98 invaluable in the design on key handling procedures. 100 4 "Lateral Signing" 102 Lateral signing refers to the use of key-signing keys and data-signing 103 keys to balance the need to change keys (avoiding discovery) and the 104 need to configure new keys in resolvers. 106 This approach has been developed for the use of TLDs in absence of a 107 signed root zone. This approach is applicable anywhere in the DNS 108 hierarchy, and will be needed by the root zone when it is signed. 110 The thought is as follows. A zone assumes that the parent is not 111 secured, hence must distribute a public key to all resolvers of 112 interest. This key is a key-signing key, it will be used to sign as 113 little as possible to minimize the risk of discovery. Other keys are 114 used to sign the zone, with these keys changed roughly once a month. 116 At any one time, the zone's key set will have the one key-signing key 117 and some number of data-signing keys. The key-signing key will sign 118 the zone key set, and the other key or keys, the zone data. 120 A resolver would start with the key-signing key configured. When data 121 arrives, it does so accompanied by a signature generated by a 122 data-signing key. The resolver then retrieves the data-signing key as 123 part of the zone key set, which is signed by the key-signing key. 124 Hence the chain is from key-signing key to data-signing key (signed by 125 key-signing key) to data (signed by data-signing key). 127 The term "lateral" signing comes from the observation that the 128 key-signing key and the data-signing key are from the same place in 129 the hierarchy (same owner name). 131 5 Getting Validation 133 In order for DNSSEC to scale, zones will need to have their parents 134 validate the zone keys. This process is the most difficult issue 135 facing DNSSEC deployment. 137 Summarizing this needed process, a child zone sends its zone key set 138 to the parent, the parent signs it and returns the data to the child. 139 This process is complicated by its volume (number of zones) and its 140 repetitiveness due - to the key discovery problem. 142 One important issue that has been raised regarding this process is 143 what the parent does with the child's keys once they are signed. One 144 school of thought is that the keys and signature are returned to the 145 child and are forgotten by the parent. Another school of though is 146 that the parent retains copies of the keys and signature, perhaps even 147 entering them into the zone file. 149 The former idea enables the child to "close the loop" security-wise by 150 verifying that the parent signed the right keys. It might be possible 151 for an attacker to intercept the submission and modify the keys. 153 The latter idea leaves the parent better prepared for a key change in 154 its zone. If the parent changes keys mid-month, or in an emergency, 155 children zones (perhaps signed monthly) need to get the new 156 signatures. On one workshop, this step was mishandled, resulting in 157 the loss of many delegations. 159 6 Changing Keys 161 When the time comes to change a zone's keys, one issue is whether it 162 is appropriate to retain old keys in the zone or to abruptly change 163 the key set (with the exception of any key-signing key). The reason 164 to retain old keys is to enable old but still valid signatures to be 165 verified in caches. Arguments for abrupt change include the 166 observation that this is the only way in which DNS can revoke 167 signatures. 169 8 Size and validity period 171 An often-asked question is what is an appropriate key size. As 172 mentioned earlier, a good guide is lacking. In general, per 173 algorithm, a longer key compared to a shorter key is more difficult to 174 discovery but takes longer to use. Longer keys can generally be used 175 longer, but signing and verification are slower. 177 The period of time in which a key should be used is an unknown 178 quantity. This will likely be a decision based upon staffing, and on 179 a calendar basis. Once a week is likely for zones requiring tight 180 security, once a month for others. 182 9 Random Numbers 184 One easily overlooked issue is the source of random numbers. A good 185 random number generator is needed to generate truly strong keys. In 186 the worst case, a random number generator always returning the same 187 number would result in the same pair of keys being generated. If a 188 zone generates a pair of keys this way and an attacker gets hold of 189 the same key generation software, it would be possible to discover the 190 private key simply by generating a pair of keys. This, by the way, 191 has already been observed in workshops. 193 It is unfortunate that some current operating systems have poor random 194 number generators. While this is improving, the machines used for key 195 generation and use should be selected carefully. 197 10 Dynamic Update 199 Dynamic update raises an issue regarding the protection of private 200 keys. As mentioned earlier, one threat is the exposure of the private 201 key. This is possible of the private key is on the same machine as 202 the name server, or even on any other reachable server. Therefore, 203 conventional wisdom is to use non-network connected machines (perhaps 204 behind a firewall) for all signing activity. 206 Dynamic update requires the server to sign data submitted to it for a 207 zone. This means the private key must be available to the name server 208 (on the network). 210 To counter this, a recommendation is offered to segregate dynamic 211 update zones from static zones. This limits the risk to static data 212 if a dynamic update zone key is exposed. In addition, some issues 213 have been discovered with signed dynamic update zones, particularly 214 the mechanism by which to refresh signatures, which also call for 215 separating crucial static data from dynamic data. 217 11 IANA Considerations 219 This document does not place any requirements on the assigned numbers 220 authority. 222 12 Security Considerations 224 This entire document is a note on security considerations. If the 225 zone key is mishandled, in a way that compromises its security, then 226 the security of its zone is compromised. 228 13 References 230 At some point. 232 14 Author's Address 234 Edward Lewis 235 236 3060 Washington Rd (Rte 97) 237 Glenwood, MD 21738 238 +1(443)259-2352 240 15 Acknowledgements 242 The following individuals and groups have made significant input into 243 the content of this document: the attendees of the NIC-SE work shop on 244 DNSSEC, May 18 and 19, 1999, also Olafur Gudmundsson, and Brian 245 Wellington. 247 A second workshop held by the CAIRN research network September 29 and 248 30th also provided input to this document. Dan Massey has provided 249 input based upon this workshop and experience with DNSSEC in CAIRN. 251 More workshops are to be acknowledged. 253 16 Full Copyright Statement 255 Copyright (C) The Internet Society (1999-2001). All Rights Reserved. 257 This document and translations of it may be copied and furnished to 258 others, and derivative works that comment on or otherwise explain it 259 or assist in its implementation may be prepared, copied, published and 260 distributed, in whole or in part, without restriction of any kind, 261 provided that the above copyright notice and this paragraph are 262 included on all such copies and derivative works. However, this 263 document itself may not be modified in any way, such as by removing 264 the copyright notice or references to the Internet Society or other 265 Internet organizations, except as needed for the purpose of developing 266 Internet standards in which case the procedures for copyrights defined 267 in the Internet Standards process must be followed, or as required to 268 translate it into languages other than English. 270 The limited permissions granted above are perpetual and will not be 271 revoked by the Internet Society or its successors or assigns. 273 This document and the information contained herein is provided on an 274 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 275 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 276 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 277 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 278 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 280 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 281 Edward Lewis NAI Labs 282 Phone: +1 443-259-2352 Email: lewis@tislabs.com 284 Dilbert is an optimist. 286 Opinions expressed are property of my evil twin, not my employer.