DNS Security Operational Considerations
RFC 2541
Document | Type |
RFC - Informational
(March 1999; No errata)
Obsoleted by RFC 4641
|
|
---|---|---|---|
Author | Donald Eastlake | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2541 (Informational) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group D. Eastlake Request for Comments: 2541 IBM Category: Informational March 1999 DNS Security Operational Considerations Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract Secure DNS is based on cryptographic techniques. A necessary part of the strength of these techniques is careful attention to the operational aspects of key and signature generation, lifetime, size, and storage. In addition, special attention must be paid to the security of the high level zones, particularly the root zone. This document discusses these operational aspects for keys and signatures used in connection with the KEY and SIG DNS resource records. Acknowledgments The contributions and suggestions of the following persons (in alphabetic order) are gratefully acknowledged: John Gilmore Olafur Gudmundsson Charlie Kaufman Eastlake Informational [Page 1] RFC 2541 DNS Security Operational Considerations March 1999 Table of Contents Abstract...................................................1 Acknowledgments............................................1 1. Introduction............................................2 2. Public/Private Key Generation...........................2 3. Public/Private Key Lifetimes............................2 4. Public/Private Key Size Considerations..................3 4.1 RSA Key Sizes..........................................3 4.2 DSS Key Sizes..........................................4 5. Private Key Storage.....................................4 6. High Level Zones, The Root Zone, and The Meta-Root Key..5 7. Security Considerations.................................5 References.................................................6 Author's Address...........................................6 Full Copyright Statement...................................7 1. Introduction This document describes operational considerations for the generation, lifetime, size, and storage of DNS cryptographic keys and signatures for use in the KEY and SIG resource records [RFC 2535]. Particular attention is paid to high level zones and the root zone. 2. Public/Private Key Generation Careful generation of all keys is a sometimes overlooked but absolutely essential element in any cryptographically secure system. The strongest algorithms used with the longest keys are still of no use if an adversary can guess enough to lower the size of the likely key space so that it can be exhaustively searched. Technical suggestions for the generation of random keys will be found in [RFC 1750]. Long term keys are particularly sensitive as they will represent a more valuable target and be subject to attack for a longer time than short period keys. It is strongly recommended that long term key generation occur off-line in a manner isolated from the network via an air gap or, at a minimum, high level secure hardware. 3. Public/Private Key Lifetimes No key should be used forever. The longer a key is in use, the greater the probability that it will have been compromised through carelessness, accident, espionage, or cryptanalysis. Furthermore, if Eastlake Informational [Page 2] RFC 2541 DNS Security Operational Considerations March 1999 key rollover is a rare event, there is an increased risk that, when the time does come to change the key, no one at the site will remember how to do it or operational problems will have developed in the key rollover procedures. While public key lifetime is a matter of local policy, these considerations imply that, unless there are extraordinary circumstances, no long term key should have a lifetime significantly over four years. In fact, a reasonable guideline for long term keys that are kept off-line and carefully guarded is a 13 month lifetime with the intent that they be replaced every year. A reasonable maximum lifetime for keys that are used for transaction security or the like and are kept on line is 36 days with the intent that they be replaced monthly or more often. In many cases, a key lifetime of somewhat over a day may be reasonable. On the other hand, public keys with too short a lifetime can lead to excessive resource consumption in re-signing data and retrieving fresh information because cached information becomes stale. In the Internet environment, almost all public keys should have lifetimes noShow full document text