DNS Security Operational Considerations
RFC 2541

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

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 no