| Network Working Group | D. Eastlake | |
| Request for Comments: 2541 | IBM | |
| Category: Informational | March 1999 |
John Gilmore
Olafur Gudmundsson
Charlie Kaufman
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.
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 no shorter than
three minutes, which is a reasonable estimate of maximum packet delay even
in unusual circumstances.
For most schemes, larger keys are more secure but slower. In addition,
larger keys increase the size of the KEY and SIG RRs. This increases
the chance of DNS UDP packet overflow and the possible necessity for using
higher overhead TCP in responses.
The recommended minimum RSA algorithm modulus size is 704 bits which is believed by the author to be secure at this time. But high level zones in the DNS tree may wish to set a higher minimum, perhaps 1000 bits, for security reasons. (Since the United States National Security Agency generally permits export of encryption systems using an RSA modulus of up to 512 bits, use of that small a modulus, i.e. n, must be considered weak.)
For an RSA key used only to secure data and not to secure other keys,
704 bits should be adequate at this time.
The idea is to have a one way information flow to the network to avoid the possibility of tampering from the network. Keeping the zone master file on-line on the network and simply cycling it through an off-line signer does not do this. The on-line version could still be tampered with if the host it resides on is compromised. For maximum security, the master copy of the zone file should be off net and should not be updated based on an unsecured network mediated communication.
This is not possible if the zone is to be dynamically updated securely [RFC 2137]. At least a private key capable of updating the SOA and NXT chain must be on line in that case.
Secure resolvers must be configured with some trusted on-line public key information (or a secure path to such a resolver) or they will be unable to authenticate. Although on line, this public key information must be protected or it could be altered so that spoofed DNS data would appear authentic.
Non-zone private keys, such as host or user keys, generally have to
be kept on line to be used for real-time purposes such as DNS transaction
security.
The root zone is the most critical of all zones. Someone controlling or compromising the security of the root zone would control the entire DNS name space of all resolvers using that root zone (except in the case of resolvers that have locally configured the public key of a subdomain). Therefore, the utmost care must be taken in the securing of the root zone. The strongest and most carefully handled keys should be used. The root zone private key should always be kept off line.
Many resolvers will start at a root server for their access to and authentication of DNS data. Securely updating an enormous population of resolvers around the world will be extremely difficult. Yet the guidelines in section 3 above would imply that the root zone private key be changed annually or more often and if it were staticly configured at all these resolvers, it would have to be updated when changed.
To permit relatively frequent change to the root zone key yet minimize exposure of the ultimate key of the DNS tree, there will be a "meta-root" key used very rarely and then only to sign a sequence of regular root key RRsets with overlapping time validity periods that are to be rolled out. The root zone contains the meta-root and current regular root KEY RR(s) signed by SIG RRs under both the meta-root and other root private key(s) themselves.
The utmost security in the storage and use of the meta-root key is essential.
The exact techniques are precautions to be used are beyond the scope of
this document. Because of its special position, it may be best to
continue with the same meta-root key for an extended period of time such
as ten to fifteen years.
| [RFC1034] | Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13,
RFC 1034, November 1987.
|
| [RFC1035] | Mockapetris, P., "Domain Names - Implementation and Specifications",
STD 13, RFC 1035, November 1987.
|
| [RFC 1750] | Eastlake, D., Crocker, S. and J. Schiller, "Randomness Requirements
for Security", RFC 1750, December 1994.
|
| [RFC2065] | Eastlake, D., and C. Kaufman, "Domain Name System Security Extensions,"
RFC 2065, January 1997.
|
| [RFC2137] | Eastlake, D., "Secure Domain Name System Dynamic Update", RFC 2137,
April 1997.
|
| [RFC2535] | Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March
1999.
|
| [RSA FAQ] | RSADSI Frequently Asked Questions periodic posting.
|
Phone: +1-914-276-2668(h)
+1-914-784-7913(w)
Fax:
+1-914-784-3833(w)
EMail: dee3@us.ibm.com
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.