DNS Security Operational Considerations
draft-ietf-dnssec-secops-02
The information below is for an old version of the document that is already published as an RFC.
| Document | Type | RFC Internet-Draft (dnssec WG) | |
|---|---|---|---|
| Author | Donald E. Eastlake 3rd | ||
| Last updated | 2013-03-02 (Latest revision 1998-11-24) | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | RFC 2541 (Informational) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-dnssec-secops-02
DNS Security Working Group Donald E. Eastlake 3rd
INTERNET-DRAFT IBM
Expires: May 1999 November 1998
DNS Security Operational Considerations
--- -------- ----------- --------------
Status of This Document
This draft, file name draft-ietf-dnssec-secops-02.txt, is intended to
be become a Best Current Practices RFC. An earlier version of some of
this material was included in [RFC 2065] but that RFC is obsoleted by
[draft-ietf-dnssec-secext2-*.txt] which does not include this
material. Distribution of this document is unlimited. Comments
should be sent to the DNS Security Working Group mailing list <dns-
security@tis.com> or to the authors.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
[Changes from last draft: update author info, file name, dates; add a
paragraph about the problems with exessively short key liftetimes; up
recommended RSA key size, drop overly specific root meta-key example]
Donald E. Eastlake 3rd [Page 1]
INTERNET-DRAFT DNS Security Operational Considerations November 1998
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
Donald E. Eastlake 3rd [Page 2]
INTERNET-DRAFT DNS Security Operational Considerations November 1998
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Acknowledgments............................................2
Table of Contents..........................................3
1. Introduction............................................4
2. Public/Private Key Generation...........................4
3. Public/Private Key Lifetimes............................4
4. Public/Private Key Size Considerations..................5
4.1 RSA Key Sizes..........................................5
4.2 DSS Key Sizes..........................................6
5. Private Key Storage.....................................6
6. High Level Zones, The Root Zone, and The Meta-Root Key..6
7. Security Considerations.................................7
References.................................................8
Author's Address...........................................9
Expiration and File Name...................................9
Donald E. Eastlake 3rd [Page 3]
INTERNET-DRAFT DNS Security Operational Considerations November 1998
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 [draft-ietf-
dnssec-secext2-*.txt]. 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
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
Donald E. Eastlake 3rd [Page 4]
INTERNET-DRAFT DNS Security Operational Considerations November 1998
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.
4. Public/Private Key Size Considerations
There are a number of factors that effect public key size choice for
use in the DNS security extension. Unfortunately, these factors
usually do not all point in the same direction. Choice of zone key
size should generally be made by the zone administrator depending on
their local conditions.
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.
4.1 RSA Key Sizes
Given a small public exponent, verification (the most common
operation) for the MD5/RSA algorithm will vary roughly with the
square of the modulus length, signing will vary with the cube of the
modulus length, and key generation (the least common operation) will
vary with the fourth power of the modulus length. The current best
algorithms for factoring a modulus and breaking RSA security vary
roughly with the 1.6 power of the modulus itself. Thus going from a
640 bit modulus to a 1280 bit modulus only increases the verification
time by a factor of 4 but may increase the work factor of breaking
the key by over 2^900.
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.
Donald E. Eastlake 3rd [Page 5]
INTERNET-DRAFT DNS Security Operational Considerations November 1998
4.2 DSS Key Sizes
DSS keys are probably roughly as strong as an RSA key of the same
length but DSS signatures are significantly smaller.
5. Private Key Storage
It is recommended that, where possible, zone private keys and the
zone file master copy be kept and used in off-line, non-network
connected, physically secure machines only. Periodically an
application can be run to add authentication to a zone by adding SIG
and NXT RRs and adding no-key type KEY RRs for subzones/algorithms
where a real KEY RR for the subzone with that algorithm is not
provided. Then the augmented file can be transferred, perhaps by
sneaker-net, to the networked zone primary server machine.
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.
6. High Level Zones, The Root Zone, and The Meta-Root Key
Higher level zones are generally more sensitive than lower level
zones. Anyone controlling or breaking the security of a zone thereby
obtains authority over all of its subdomains (except in the case of
resolvers that have locally configured the public key of a
subdomain). Therefore, extra care should be taken with high level
Donald E. Eastlake 3rd [Page 6]
INTERNET-DRAFT DNS Security Operational Considerations November 1998
zones and strong keys used.
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.
7. Security Considerations
The entirety of this document is concerned with operational
considerations of public/private key pair DNS Security.
Donald E. Eastlake 3rd [Page 7]
INTERNET-DRAFT DNS Security Operational Considerations November 1998
References
[RFC 1034] - P. Mockapetris, "Domain Names - Concepts and
Facilities", STD 13, November 1987.
[RFC 1035] - P. Mockapetris, "Domain Names - Implementation and
Specifications", STD 13, November 1987.
[RFC 1750] - D. Eastlake, S. Crocker, and J. Schiller, "Randomness
Requirements for Security", December 1994.
[RFC 2065] - Donald Eastlake, Charles Kaufman, "Domain Name System
Security Extensions", 01/03/1997.
[RFC 2137] - Donald Eastlake, "Secure Domain Name System Dynamic
Update", 04/21/1997.
draft-ietf-dnssec-secext2-*.txt - D. Eastlake, "Domain Name System
Security Extensions".
[RSA FAQ] - RSADSI Frequently Asked Questions periodic posting.
Donald E. Eastlake 3rd [Page 8]
INTERNET-DRAFT DNS Security Operational Considerations November 1998
Author's Address
Donald E. Eastlake 3rd
IBM
318 Acton Street
Carlisle, MA 01741 USA
Telephone: +1 978-287-4877
+1 914-784-7913
fax: +1 978-371-7148
email: dee3@us.ibm.com
Expiration and File Name
This draft expires May 1999.
Its file name is draft-ietf-dnssec-secops-02.txt.
Donald E. Eastlake 3rd [Page 9]