| blob | a62ed2b48677528e9f12364400b02be7b5e5ce07 |
7 Network Working Group D. Eastlake
8 Request for Comments: 2541 IBM
9 Category: Informational March 1999
12 DNS Security Operational Considerations
14 Status of this Memo
16 This memo provides information for the Internet community. It does
17 not specify an Internet standard of any kind. Distribution of this
18 memo is unlimited.
20 Copyright Notice
22 Copyright (C) The Internet Society (1999). All Rights Reserved.
24 Abstract
26 Secure DNS is based on cryptographic techniques. A necessary part of
27 the strength of these techniques is careful attention to the
28 operational aspects of key and signature generation, lifetime, size,
29 and storage. In addition, special attention must be paid to the
30 security of the high level zones, particularly the root zone. This
31 document discusses these operational aspects for keys and signatures
32 used in connection with the KEY and SIG DNS resource records.
34 Acknowledgments
36 The contributions and suggestions of the following persons (in
37 alphabetic order) are gratefully acknowledged:
39 John Gilmore
40 Olafur Gudmundsson
41 Charlie Kaufman
58 Eastlake Informational [Page 1]
59 \f
60 RFC 2541 DNS Security Operational Considerations March 1999
63 Table of Contents
65 Abstract...................................................1
66 Acknowledgments............................................1
67 1. Introduction............................................2
68 2. Public/Private Key Generation...........................2
69 3. Public/Private Key Lifetimes............................2
70 4. Public/Private Key Size Considerations..................3
71 4.1 RSA Key Sizes..........................................3
72 4.2 DSS Key Sizes..........................................4
73 5. Private Key Storage.....................................4
74 6. High Level Zones, The Root Zone, and The Meta-Root Key..5
75 7. Security Considerations.................................5
76 References.................................................6
77 Author's Address...........................................6
78 Full Copyright Statement...................................7
80 1. Introduction
82 This document describes operational considerations for the
83 generation, lifetime, size, and storage of DNS cryptographic keys and
84 signatures for use in the KEY and SIG resource records [RFC 2535].
85 Particular attention is paid to high level zones and the root zone.
87 2. Public/Private Key Generation
89 Careful generation of all keys is a sometimes overlooked but
90 absolutely essential element in any cryptographically secure system.
91 The strongest algorithms used with the longest keys are still of no
92 use if an adversary can guess enough to lower the size of the likely
93 key space so that it can be exhaustively searched. Technical
94 suggestions for the generation of random keys will be found in [RFC
95 1750].
97 Long term keys are particularly sensitive as they will represent a
98 more valuable target and be subject to attack for a longer time than
99 short period keys. It is strongly recommended that long term key
100 generation occur off-line in a manner isolated from the network via
101 an air gap or, at a minimum, high level secure hardware.
103 3. Public/Private Key Lifetimes
105 No key should be used forever. The longer a key is in use, the
106 greater the probability that it will have been compromised through
107 carelessness, accident, espionage, or cryptanalysis. Furthermore, if
114 Eastlake Informational [Page 2]
115 \f
116 RFC 2541 DNS Security Operational Considerations March 1999
119 key rollover is a rare event, there is an increased risk that, when
120 the time does come to change the key, no one at the site will
121 remember how to do it or operational problems will have developed in
122 the key rollover procedures.
124 While public key lifetime is a matter of local policy, these
125 considerations imply that, unless there are extraordinary
126 circumstances, no long term key should have a lifetime significantly
127 over four years. In fact, a reasonable guideline for long term keys
128 that are kept off-line and carefully guarded is a 13 month lifetime
129 with the intent that they be replaced every year. A reasonable
130 maximum lifetime for keys that are used for transaction security or
131 the like and are kept on line is 36 days with the intent that they be
132 replaced monthly or more often. In many cases, a key lifetime of
133 somewhat over a day may be reasonable.
135 On the other hand, public keys with too short a lifetime can lead to
136 excessive resource consumption in re-signing data and retrieving
137 fresh information because cached information becomes stale. In the
138 Internet environment, almost all public keys should have lifetimes no
139 shorter than three minutes, which is a reasonable estimate of maximum
140 packet delay even in unusual circumstances.
142 4. Public/Private Key Size Considerations
144 There are a number of factors that effect public key size choice for
145 use in the DNS security extension. Unfortunately, these factors
146 usually do not all point in the same direction. Choice of zone key
147 size should generally be made by the zone administrator depending on
148 their local conditions.
150 For most schemes, larger keys are more secure but slower. In
151 addition, larger keys increase the size of the KEY and SIG RRs. This
152 increases the chance of DNS UDP packet overflow and the possible
153 necessity for using higher overhead TCP in responses.
155 4.1 RSA Key Sizes
157 Given a small public exponent, verification (the most common
158 operation) for the MD5/RSA algorithm will vary roughly with the
159 square of the modulus length, signing will vary with the cube of the
160 modulus length, and key generation (the least common operation) will
161 vary with the fourth power of the modulus length. The current best
162 algorithms for factoring a modulus and breaking RSA security vary
163 roughly with the 1.6 power of the modulus itself. Thus going from a
164 640 bit modulus to a 1280 bit modulus only increases the verification
165 time by a factor of 4 but may increase the work factor of breaking
166 the key by over 2^900.
170 Eastlake Informational [Page 3]
171 \f
172 RFC 2541 DNS Security Operational Considerations March 1999
175 The recommended minimum RSA algorithm modulus size is 704 bits which
176 is believed by the author to be secure at this time. But high level
177 zones in the DNS tree may wish to set a higher minimum, perhaps 1000
178 bits, for security reasons. (Since the United States National
179 Security Agency generally permits export of encryption systems using
180 an RSA modulus of up to 512 bits, use of that small a modulus, i.e.
181 n, must be considered weak.)
183 For an RSA key used only to secure data and not to secure other keys,
184 704 bits should be adequate at this time.
186 4.2 DSS Key Sizes
188 DSS keys are probably roughly as strong as an RSA key of the same
189 length but DSS signatures are significantly smaller.
191 5. Private Key Storage
193 It is recommended that, where possible, zone private keys and the
194 zone file master copy be kept and used in off-line, non-network
195 connected, physically secure machines only. Periodically an
196 application can be run to add authentication to a zone by adding SIG
197 and NXT RRs and adding no-key type KEY RRs for subzones/algorithms
198 where a real KEY RR for the subzone with that algorithm is not
199 provided. Then the augmented file can be transferred, perhaps by
200 sneaker-net, to the networked zone primary server machine.
202 The idea is to have a one way information flow to the network to
203 avoid the possibility of tampering from the network. Keeping the
204 zone master file on-line on the network and simply cycling it through
205 an off-line signer does not do this. The on-line version could still
206 be tampered with if the host it resides on is compromised. For
207 maximum security, the master copy of the zone file should be off net
208 and should not be updated based on an unsecured network mediated
209 communication.
211 This is not possible if the zone is to be dynamically updated
212 securely [RFC 2137]. At least a private key capable of updating the
213 SOA and NXT chain must be on line in that case.
215 Secure resolvers must be configured with some trusted on-line public
216 key information (or a secure path to such a resolver) or they will be
217 unable to authenticate. Although on line, this public key
218 information must be protected or it could be altered so that spoofed
219 DNS data would appear authentic.
226 Eastlake Informational [Page 4]
227 \f
228 RFC 2541 DNS Security Operational Considerations March 1999
231 Non-zone private keys, such as host or user keys, generally have to
232 be kept on line to be used for real-time purposes such as DNS
233 transaction security.
235 6. High Level Zones, The Root Zone, and The Meta-Root Key
237 Higher level zones are generally more sensitive than lower level
238 zones. Anyone controlling or breaking the security of a zone thereby
239 obtains authority over all of its subdomains (except in the case of
240 resolvers that have locally configured the public key of a
241 subdomain). Therefore, extra care should be taken with high level
242 zones and strong keys used.
244 The root zone is the most critical of all zones. Someone controlling
245 or compromising the security of the root zone would control the
246 entire DNS name space of all resolvers using that root zone (except
247 in the case of resolvers that have locally configured the public key
248 of a subdomain). Therefore, the utmost care must be taken in the
249 securing of the root zone. The strongest and most carefully handled
250 keys should be used. The root zone private key should always be kept
251 off line.
253 Many resolvers will start at a root server for their access to and
254 authentication of DNS data. Securely updating an enormous population
255 of resolvers around the world will be extremely difficult. Yet the
256 guidelines in section 3 above would imply that the root zone private
257 key be changed annually or more often and if it were staticly
258 configured at all these resolvers, it would have to be updated when
259 changed.
261 To permit relatively frequent change to the root zone key yet
262 minimize exposure of the ultimate key of the DNS tree, there will be
263 a "meta-root" key used very rarely and then only to sign a sequence
264 of regular root key RRsets with overlapping time validity periods
265 that are to be rolled out. The root zone contains the meta-root and
266 current regular root KEY RR(s) signed by SIG RRs under both the
267 meta-root and other root private key(s) themselves.
269 The utmost security in the storage and use of the meta-root key is
270 essential. The exact techniques are precautions to be used are
271 beyond the scope of this document. Because of its special position,
272 it may be best to continue with the same meta-root key for an
273 extended period of time such as ten to fifteen years.
275 7. Security Considerations
277 The entirety of this document is concerned with operational
278 considerations of public/private key pair DNS Security.
282 Eastlake Informational [Page 5]
283 \f
284 RFC 2541 DNS Security Operational Considerations March 1999
287 References
289 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
290 Facilities", STD 13, RFC 1034, November 1987.
292 [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
293 Specifications", STD 13, RFC 1035, November 1987.
295 [RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
296 Requirements for Security", RFC 1750, December 1994.
298 [RFC 2065] Eastlake, D. and C. Kaufman, "Domain Name System
299 Security Extensions", RFC 2065, January 1997.
301 [RFC 2137] Eastlake, D., "Secure Domain Name System Dynamic
302 Update", RFC 2137, April 1997.
304 [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
305 RFC 2535, March 1999.
307 [RSA FAQ] RSADSI Frequently Asked Questions periodic posting.
309 Author's Address
311 Donald E. Eastlake 3rd
312 IBM
313 65 Shindegan Hill Road, RR #1
314 Carmel, NY 10512
316 Phone: +1-914-276-2668(h)
317 +1-914-784-7913(w)
318 Fax: +1-914-784-3833(w)
319 EMail: dee3@us.ibm.com
338 Eastlake Informational [Page 6]
339 \f
340 RFC 2541 DNS Security Operational Considerations March 1999
343 Full Copyright Statement
345 Copyright (C) The Internet Society (1999). All Rights Reserved.
347 This document and translations of it may be copied and furnished to
348 others, and derivative works that comment on or otherwise explain it
349 or assist in its implementation may be prepared, copied, published
350 and distributed, in whole or in part, without restriction of any
351 kind, provided that the above copyright notice and this paragraph are
352 included on all such copies and derivative works. However, this
353 document itself may not be modified in any way, such as by removing
354 the copyright notice or references to the Internet Society or other
355 Internet organizations, except as needed for the purpose of
356 developing Internet standards in which case the procedures for
357 copyrights defined in the Internet Standards process must be
358 followed, or as required to translate it into languages other than
359 English.
361 The limited permissions granted above are perpetual and will not be
362 revoked by the Internet Society or its successors or assigns.
364 This document and the information contained herein is provided on an
365 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
366 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
367 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
368 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
369 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
394 Eastlake Informational [Page 7]
395 \f