tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6781

 Errata 
Informational
Pages: 71
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: DNSOP

DNSSEC Operational Practices, Version 2

Part 1 of 4, p. 1 to 18
None       Next RFC Part

Obsoletes:    4641


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                        O. Kolkman
Request for Comments: 6781                                    W. Mekking
Obsoletes: 4641                                               NLnet Labs
Category: Informational                                        R. Gieben
ISSN: 2070-1721                                                SIDN Labs
                                                           December 2012


                DNSSEC Operational Practices, Version 2

Abstract

   This document describes a set of practices for operating the DNS with
   security extensions (DNSSEC).  The target audience is zone
   administrators deploying DNSSEC.

   The document discusses operational aspects of using keys and
   signatures in the DNS.  It discusses issues of key generation, key
   storage, signature generation, key rollover, and related policies.

   This document obsoletes RFC 4641, as it covers more operational
   ground and gives more up-to-date requirements with respect to key
   sizes and the DNSSEC operations.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6781.

Page 2 
Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1. Introduction ....................................................4
      1.1. The Use of the Term 'key' ..................................5
      1.2. Time Definitions ...........................................6
   2. Keeping the Chain of Trust Intact ...............................6
   3. Key Generation and Storage ......................................7
      3.1. Operational Motivation for Zone Signing Keys and
           Key Signing Keys ...........................................8
      3.2. Practical Consequences of KSK and ZSK Separation ..........10
           3.2.1. Rolling a KSK That Is Not a Trust Anchor ...........10
           3.2.2. Rolling a KSK That Is a Trust Anchor ...............11
           3.2.3. The Use of the SEP Flag ............................12
      3.3. Key Effectivity Period ....................................12
      3.4. Cryptographic Considerations ..............................14
           3.4.1. Signature Algorithm ................................14
           3.4.2. Key Sizes ..........................................14
           3.4.3. Private Key Storage ................................16
           3.4.4. Key Generation .....................................17
           3.4.5. Differentiation for 'High-Level' Zones? ............17

Top      ToC       Page 3 
   4. Signature Generation, Key Rollover, and Related Policies .......18
      4.1. Key Rollovers .............................................18
           4.1.1. Zone Signing Key Rollovers .........................18
                  4.1.1.1. Pre-Publish Zone Signing Key Rollover .....19
                  4.1.1.2. Double-Signature Zone Signing Key Rollover 21
                  4.1.1.3. Pros and Cons of the Schemes ..............23
           4.1.2. Key Signing Key Rollovers ..........................23
                  4.1.2.1. Special Considerations for RFC 5011
                           KSK Rollover ..............................26
           4.1.3. Single-Type Signing Scheme Key Rollover ............26
           4.1.4. Algorithm Rollovers ................................28
                  4.1.4.1. Single-Type Signing Scheme
                           Algorithm Rollover ........................32
                  4.1.4.2. Algorithm Rollover, RFC 5011 Style ........32
                  4.1.4.3. Single Signing Type Algorithm
                           Rollover, RFC 5011 Style ..................33
                  4.1.4.4. NSEC-to-NSEC3 Algorithm Rollover ..........34
           4.1.5. Considerations for Automated Key Rollovers .........34
      4.2. Planning for Emergency Key Rollover .......................35
           4.2.1. KSK Compromise .....................................35
                  4.2.1.1. Emergency Key Rollover Keeping the
                           Chain of Trust Intact .....................36
                  4.2.1.2. Emergency Key Rollover Breaking
                           the Chain of Trust ........................37
           4.2.2. ZSK Compromise .....................................37
           4.2.3. Compromises of Keys Anchored in Resolvers ..........38
           4.2.4. Stand-By Keys ......................................38
      4.3. Parent Policies ...........................................39
           4.3.1. Initial Key Exchanges and Parental Policies
                  Considerations .....................................39
           4.3.2. Storing Keys or Hashes? ............................40
           4.3.3. Security Lameness ..................................40
           4.3.4. DS Signature Validity Period .......................41
           4.3.5. Changing DNS Operators .............................42
                  4.3.5.1. Cooperating DNS Operators .................42
                  4.3.5.2. Non-Cooperating DNS Operators .............44
      4.4. Time in DNSSEC ............................................46
           4.4.1. Time Considerations ................................46
           4.4.2. Signature Validity Periods .........................48
                  4.4.2.1. Maximum Value .............................48
                  4.4.2.2. Minimum Value .............................49
                  4.4.2.3. Differentiation between RRsets ............50

Top      ToC       Page 4 
   5. "Next Record" Types ............................................51
      5.1. Differences between NSEC and NSEC3 ........................51
      5.2. NSEC or NSEC3 .............................................52
      5.3. NSEC3 Parameters ..........................................53
           5.3.1. NSEC3 Algorithm ....................................53
           5.3.2. NSEC3 Iterations ...................................53
           5.3.3. NSEC3 Salt .........................................54
           5.3.4. Opt-Out ............................................54
   6. Security Considerations ........................................54
   7. Acknowledgments ................................................55
   8. Contributors ...................................................55
   9. References .....................................................56
      9.1. Normative References ......................................56
      9.2. Informative References ....................................56
   Appendix A. Terminology ...........................................59
   Appendix B. Typographic Conventions ...............................61
   Appendix C. Transition Figures for Special Cases of Algorithm
               Rollovers .............................................64
   Appendix D. Transition Figure for Changing DNS Operators ..........68
   Appendix E. Summary of Changes from RFC 4641 ......................70

1.  Introduction

   This document describes how to run a DNS Security (DNSSEC)-enabled
   environment.  It is intended for operators who have knowledge of the
   DNS (see RFC 1034 [RFC1034] and RFC 1035 [RFC1035]) and want to
   deploy DNSSEC (RFC 4033 [RFC4033], RFC 4034 [RFC4034], RFC 4035
   [RFC4035], and RFC 5155 [RFC5155]).  The focus of the document is on
   serving authoritative DNS information and is aimed at zone owners,
   name server operators, registries, registrars, and registrants.  It
   assumes that there is no direct relationship between those entities
   and the operators of validating recursive name servers (validators).

   During workshops and early operational deployment, operators and
   system administrators have gained experience about operating the DNS
   with security extensions (DNSSEC).  This document translates these
   experiences into a set of practices for zone administrators.
   Although the DNS Root has been signed since July 15, 2010 and now
   more than 80 secure delegations are provisioned in the root, at the
   time of this writing there still exists relatively little experience
   with DNSSEC in production environments below the Top-Level Domain
   (TLD) level; this document should therefore explicitly not be seen as
   representing 'Best Current Practices'.  Instead, it describes the
   decisions that should be made when deploying DNSSEC, gives the
   choices available for each one, and provides some operational
   guidelines.  The document does not give strong recommendations.  That
   may be the subject for a future version of this document.

Top      ToC       Page 5 
   The procedures herein are focused on the maintenance of signed zones
   (i.e., signing and publishing zones on authoritative servers).  It is
   intended that maintenance of zones, such as re-signing or key
   rollovers, be transparent to any verifying clients.

   The structure of this document is as follows.  In Section 2, we
   discuss the importance of keeping the "chain of trust" intact.
   Aspects of key generation and storage of keys are discussed in
   Section 3; the focus in this section is mainly on the security of the
   private part of the key(s).  Section 4 describes considerations
   concerning the public part of the keys.  Sections 4.1 and 4.2 deal
   with the rollover, or replacement, of keys.  Section 4.3 discusses
   considerations on how parents deal with their children's public keys
   in order to maintain chains of trust.  Section 4.4 covers all kinds
   of timing issues around key publication.  Section 5 covers the
   considerations regarding selecting and using the NSEC or NSEC3
   [RFC5155] Resource Record.

   The typographic conventions used in this document are explained in
   Appendix B.

   Since we describe operational suggestions and there are no protocol
   specifications, the RFC 2119 [RFC2119] language does not apply to
   this document, though we do use quotes from other documents that do
   include the RFC 2119 language.

   This document obsoletes RFC 4641 [RFC4641].

1.1.  The Use of the Term 'key'

   It is assumed that the reader is familiar with the concept of
   asymmetric cryptography, or public-key cryptography, on which DNSSEC
   is based (see the definition of 'asymmetric cryptography' in RFC 4949
   [RFC4949]).  Therefore, this document will use the term 'key' rather
   loosely.  Where it is written that 'a key is used to sign data', it
   is assumed that the reader understands that it is the private part of
   the key pair that is used for signing.  It is also assumed that the
   reader understands that the public part of the key pair is published
   in the DNSKEY Resource Record (DNSKEY RR) and that it is the public
   part that is used in signature verification.

Top      ToC       Page 6 
1.2.  Time Definitions

   In this document, we will be using a number of time-related terms.
   The following definitions apply:

   Signature validity period:  The period that a signature is valid.  It
      starts at the (absolute) time specified in the signature inception
      field of the RRSIG RR and ends at the (absolute) time specified in
      the expiration field of the RRSIG RR.  The document sometimes also
      uses the term 'validity period', which means the same.

   Signature publication period:  The period that a signature is
      published.  It starts at the time the signature is introduced in
      the zone for the first time and ends at the time when the
      signature is removed or replaced with a new signature.  After one
      stops publishing an RRSIG in a zone, it may take a while before
      the RRSIG has expired from caches and has actually been removed
      from the DNS.

   Key effectivity period:  The period during which a key pair is
      expected to be effective.  It is defined as the time between the
      earliest inception time stamp and the last expiration date of any
      signature made with this key, regardless of any discontinuity in
      the use of the key.  The key effectivity period can span multiple
      signature validity periods.

   Maximum/Minimum Zone Time to Live (TTL):  The maximum or minimum
      value of the TTLs from the complete set of RRs in a zone, that are
      used by validators or resolvers.  Note that the minimum TTL is not
      the same as the MINIMUM field in the SOA RR.  See RFC 2308
      [RFC2308] for more information.

2.  Keeping the Chain of Trust Intact

   Maintaining a valid chain of trust is important because broken chains
   of trust will result in data being marked as Bogus (as defined in
   RFC 4033 [RFC4033] Section 5), which may cause entire (sub)domains to
   become invisible to verifying clients.  The administrators of secured
   zones need to realize that, to verifying clients, their zone is part
   of a chain of trust.

   As mentioned in the introduction, the procedures herein are intended
   to ensure that maintenance of zones, such as re-signing or key
   rollovers, will be transparent to the verifying clients on the
   Internet.

Top      ToC       Page 7 
   Administrators of secured zones will need to keep in mind that data
   published on an authoritative primary server will not be immediately
   seen by verifying clients; it may take some time for the data to be
   transferred to other (secondary) authoritative name servers and
   clients may be fetching data from caching non-authoritative servers.
   In this light, note that the time until the data is available on the
   slave can be negligible when using NOTIFY [RFC1996] and Incremental
   Zone Transfer (IXFR) [RFC1995].  It increases when Authoritative
   (full) Zone Transfers (AXFRs) are used in combination with NOTIFY.
   It increases even more if you rely on the full zone transfers being
   based only on the SOA timing parameters for refresh.

   For the verifying clients, it is important that data from secured
   zones can be used to build chains of trust, regardless of whether the
   data came directly from an authoritative server, a caching name
   server, or some middle box.  Only by carefully using the available
   timing parameters can a zone administrator ensure that the data
   necessary for verification can be obtained.

   The responsibility for maintaining the chain of trust is shared by
   administrators of secured zones in the chain of trust.  This is most
   obvious in the case of a 'key compromise' when a tradeoff must be
   made between maintaining a valid chain of trust and replacing the
   compromised keys as soon as possible.  Then zone administrators will
   have to decide between keeping the chain of trust intact -- thereby
   allowing for attacks with the compromised key -- or deliberately
   breaking the chain of trust and making secured subdomains invisible
   to security-aware resolvers (also see Section 4.2).

3.  Key Generation and Storage

   This section describes a number of considerations with respect to the
   use of keys.  For the design of an operational procedure for key
   generation and storage, a number of decisions need to be made:

   o  Does one differentiate between Zone Signing Keys and Key Signing
      Keys or is the use of one type of key sufficient?

   o  Are Key Signing Keys (likely to be) in use as trust anchors
      [RFC4033]?

   o  What are the timing parameters that are allowed by the operational
      requirements?

   o  What are the cryptographic parameters that fit the operational
      need?

Top      ToC       Page 8 
   The following section discusses the considerations that need to be
   taken into account when making those choices.

3.1.  Operational Motivation for Zone Signing Keys and Key Signing Keys

   The DNSSEC validation protocol does not distinguish between different
   types of DNSKEYs.  The motivations to differentiate between keys are
   purely operational; validators will not make a distinction.

   For operational reasons, described below, it is possible to designate
   one or more keys to have the role of Key Signing Keys (KSKs).  These
   keys will only sign the apex DNSKEY RRset in a zone.  Other keys can
   be used to sign all the other RRsets in a zone that require
   signatures.  They are referred to as Zone Signing Keys (ZSKs).  In
   cases where the differentiation between the KSK and ZSK is not made,
   i.e., where keys have the role of both KSK and ZSK, we talk about a
   Single-Type Signing Scheme.

   If the two functions are separated, then for almost any method of key
   management and zone signing, the KSK is used less frequently than the
   ZSK.  Once a DNSKEY RRset is signed with the KSK, all the keys in the
   RRset can be used as ZSKs.  If there has been an event that increases
   the risk that a ZSK is compromised, it can be simply replaced with a
   ZSK rollover.  The new RRset is then re-signed with the KSK.

   Changing a key that is a Secure Entry Point (SEP) [RFC4034] for a
   zone can be relatively expensive, as it involves interaction with
   third parties: When a key is only pointed to by a Delegation Signer
   (DS) [RFC4034] record in the parent zone, one needs to complete the
   interaction with the parent and wait for the updated DS record to
   appear in the DNS.  In the case where a key is configured as a trust
   anchor, one has to wait until one has sufficient confidence that all
   trust anchors have been replaced.  In fact, it may be that one is not
   able to reach the complete user-base with information about the key
   rollover.

   Given the assumption that for KSKs the SEP flag is set, the KSK can
   be distinguished from a ZSK by examining the flag field in the DNSKEY
   RR: If the flag field is an odd number, it is a KSK; otherwise, it is
   a ZSK.

   There is also a risk that keys can be compromised through theft or
   loss.  For keys that are installed on file-systems of name servers
   that are connected to the network (e.g., for dynamic updates), that
   risk is relatively high.  Where keys are stored on Hardware Security
   Modules (HSMs) or stored off-line, such risk is relatively low.
   However, storing keys off-line or with more limitations on access
   control has a negative effect on the operational flexibility.  By

Top      ToC       Page 9 
   separating the KSK and ZSK functionality, these risks can be managed
   while making the tradeoff against the involved costs.  For example, a
   KSK can be stored off-line or with more limitations on access control
   than ZSKs, which need to be readily available for operational
   purposes such as the addition or deletion of zone data.  A KSK stored
   on a smartcard that is kept in a safe, combined with a ZSK stored on
   a file-system accessible by operators for daily routine use, may
   provide better protection against key compromise without losing much
   operational flexibility.  It must be said that some HSMs give the
   option to have your keys online, giving more protection and hardly
   affecting the operational flexibility.  In those cases, a KSK-ZSK
   split is not more beneficial than the Single-Type Signing Scheme.

   It is worth mentioning that there's not much point in obsessively
   protecting the key if you don't protect the zone files, which also
   live on the file-systems.

   Finally, there is a risk of cryptanalysis of the key material.  The
   costs of such analysis are correlated to the length of the key.
   However, cryptanalysis arguments provide no strong motivation for a
   KSK/ZSK split.  Suppose one differentiates between a KSK and a ZSK,
   whereby the KSK effectivity period is X times the ZSK effectivity
   period.  Then, in order for the resistance to cryptanalysis to be the
   same for the KSK and the ZSK, the KSK needs to be X times stronger
   than the ZSK.  Since for all practical purposes X will be somewhere
   on the order of 10 to 100, the associated key sizes will vary only by
   about a byte in size for symmetric keys.  When translated to
   asymmetric keys, the size difference is still too insignificant to
   warrant a key-split; it only marginally affects the packet size and
   signing speed.

   The arguments for differentiation between the ZSK and KSK are weakest
   when:

   o  the exposure to risk is low (e.g., when keys are stored on HSMs);

   o  one can be certain that a key is not used as a trust anchor;

   o  maintenance of the various keys cannot be performed through tools
      (is prone to human error); and

   o  the interaction through the child-parent provisioning chain -- in
      particular, the timely appearance of a new DS record in the parent
      zone in emergency situations -- is predictable.

Top      ToC       Page 10 
   If the above arguments hold, then the costs of the operational
   complexity of a KSK-ZSK split may outweigh the costs of operational
   flexibility, and choosing a Single-Type Signing Scheme is a
   reasonable option.  In other cases, we advise that the separation
   between KSKs and ZSKs is made.

3.2.  Practical Consequences of KSK and ZSK Separation

   A key that acts only as a Zone Signing Key is used to sign all the
   data except the DNSKEY RRset in a zone on a regular basis.  When a
   ZSK is to be rolled, no interaction with the parent is needed.  This
   allows for a relatively short key effectivity period.

   A key with only the Key Signing Key role is to be used to sign the
   DNSKEY RRs in a zone.  If a KSK is to be rolled, there may be
   interactions with other parties.  These can include the
   administrators of the parent zone or administrators of verifying
   resolvers that have the particular key configured as secure entry
   points.  In the latter case, everyone relying on the trust anchor
   needs to roll over to the new key, a process that may be subject to
   stability costs if automated trust anchor rollover mechanisms (e.g.,
   RFC 5011 [RFC5011]) are not in place.  Hence, the key effectivity
   period of these keys can and should be made much longer.

3.2.1.  Rolling a KSK That Is Not a Trust Anchor

   There are three schools of thought on rolling a KSK that is not a
   trust anchor:

   1.  It should be done frequently and regularly (possibly every few
       months), so that a key rollover remains an operational routine.

   2.  It should be done frequently but irregularly.  "Frequently" means
       every few months, again based on the argument that a rollover is
       a practiced and common operational routine; "irregular" means
       with a large jitter, so that third parties do not start to rely
       on the key and will not be tempted to configure it as a trust
       anchor.

   3.  It should only be done when it is known or strongly suspected
       that the key can be or has been compromised, or in conjunction
       with operator change policies and procedures, like when a new
       algorithm or key storage is required.

   There is no widespread agreement on which of these three schools of
   thought is better for different deployments of DNSSEC.  There is a
   stability cost every time a non-anchor KSK is rolled over, but it is
   possibly low if the communication between the child and the parent is

Top      ToC       Page 11 
   good.  On the other hand, the only completely effective way to tell
   if the communication is good is to test it periodically.  Thus,
   rolling a KSK with a parent is only done for two reasons: to test and
   verify the rolling system to prepare for an emergency, and in the
   case of (preventing) an actual emergency.

   Finally, in most cases a zone administrator cannot be fully certain
   that the zone's KSK is not in use as a trust anchor somewhere.  While
   the configuration of trust anchors is not the responsibility of the
   zone administrator, there may be stability costs for the validator
   administrator that (wrongfully) configured the trust anchor when the
   zone administrator rolls a KSK.

3.2.2.  Rolling a KSK That Is a Trust Anchor

   The same operational concerns apply to the rollover of KSKs that are
   used as trust anchors: If a trust anchor replacement is done
   incorrectly, the entire domain that the trust anchor covers will
   become Bogus until the trust anchor is corrected.

   In a large number of cases, it will be safe to work from the
   assumption that one's keys are not in use as trust anchors.  If a
   zone administrator publishes a DNSSEC signing policy and/or a DNSSEC
   practice statement [DNSSEC-DPS], that policy or statement should be
   explicit regarding whether or not the existence of trust anchors will
   be taken into account.  There may be cases where local policies
   enforce the configuration of trust anchors on zones that are mission
   critical (e.g., in enterprises where the trust anchor for the
   enterprise domain is configured in the enterprise's validator).  It
   is expected that the zone administrators are aware of such
   circumstances.

   One can argue that because of the difficulty of getting all users of
   a trust anchor to replace an old trust anchor with a new one, a KSK
   that is a trust anchor should never be rolled unless it is known or
   strongly suspected that the key has been compromised.  In other
   words, the costs of a KSK rollover are prohibitively high because
   some users cannot be reached.

   However, the "operational habit" argument also applies to trust
   anchor reconfiguration at the clients' validators.  If a short key
   effectivity period is used and the trust anchor configuration has to
   be revisited on a regular basis, the odds that the configuration
   tends to be forgotten are smaller.  In fact, the costs for those
   users can be minimized by automating the rollover with RFC 5011
   [RFC5011] and by rolling the key regularly (and advertising such) so

Top      ToC       Page 12 
   that the operators of validating resolvers will put the appropriate
   mechanism in place to deal with these stability costs: In other
   words, budget for these costs instead of incurring them unexpectedly.

   It is therefore preferable to roll KSKs that are expected to be used
   as trust anchors on a regular basis if and only if those rollovers
   can be tracked using standardized (e.g., RFC 5011 [RFC5011])
   mechanisms.

3.2.3.  The Use of the SEP Flag

   The so-called SEP [RFC4035] flag can be used to distinguish between
   keys that are intended to be used as the secure entry point into the
   zone when building chains of trust, i.e., they are (to be) pointed to
   by parental DS RRs or configured as a trust anchor.

   While the SEP flag does not play any role in validation, it is used
   in practice for operational purposes such as for the rollover
   mechanism described in RFC 5011 [RFC5011].  The common convention is
   to set the SEP flag on any key that is used for key exchanges with
   the parent and/or potentially used for configuration as a trust
   anchor.  Therefore, it is suggested that the SEP flag be set on keys
   that are used as KSKs and not on keys that are used as ZSKs, while in
   those cases where a distinction between a KSK and ZSK is not made
   (i.e., for a Single-Type Signing Scheme), it is suggested that the
   SEP flag be set on all keys.

   Note: Some signing tools may assume a KSK/ZSK split and use the
   (non-)presence of the SEP flag to determine which key is to be used
   for signing zone data; these tools may get confused when a Single-
   Type Signing Scheme is used.

3.3.  Key Effectivity Period

   In general, the available key length sets an upper limit on the key
   effectivity period.  For all practical purposes, it is sufficient to
   define the key effectivity period based on purely operational
   requirements and match the key length to that value.  Ignoring the
   operational perspective, a reasonable effectivity period for KSKs
   that have corresponding DS records in the parent zone is on the order
   of two decades or longer.  That is, if one does not plan to test the
   rollover procedure, the key should be effective essentially forever
   and only rolled over in case of emergency.

   When one opts for a regular key rollover, a reasonable key
   effectivity period for KSKs that have a parent zone is one year,
   meaning you have the intent to replace them after 12 months.  The key
   effectivity period is merely a policy parameter and should not be

Top      ToC       Page 13 
   considered a constant value.  For example, the real key effectivity
   period may be a little bit longer than 12 months, because not all
   actions needed to complete the rollover could be finished in time.

   As argued above, this annual rollover gives an operational practice
   of rollovers for both the zone and validator administrators.
   Besides, in most environments a year is a time span that is easily
   planned and communicated.

   Where keys are stored online and the exposure to various threats of
   compromise is fairly high, an intended key effectivity period of a
   month is reasonable for Zone Signing Keys.

   Although very short key effectivity periods are theoretically
   possible, when replacing keys one has to take into account the
   rollover considerations discussed in Sections 4.1 and 4.4.  Key
   replacement endures for a couple of Maximum Zone TTLs, depending on
   the rollover scenario.  Therefore, a multiple of Maximum Zone TTL
   durations is a reasonable lower limit on the key effectivity period.
   Forcing a shorter key effectivity period will result in an
   unnecessary and inconveniently large DNSKEY RRset published in the
   zone.

   The motivation for having the ZSK's effectivity period shorter than
   the KSK's effectivity period is rooted in the operational
   consideration that it is more likely that operators have more
   frequent read access to the ZSK than to the KSK.  Thus, in cases
   where the ZSK cannot be afforded the same level of protection as the
   KSK (such as when zone keys are kept online), and where the risk of
   unauthorized disclosure of the ZSK's private key is not negligible
   (e.g., when HSMs are not in use), the ZSK's effectivity period should
   be kept shorter than the KSK's effectivity period.

   In fact, if the risk of loss, theft, or other compromise is the same
   for a ZSK and a KSK, there is little reason to choose different
   effectivity periods for ZSKs and KSKs.  And when the split between
   ZSKs and KSKs is not made, the argument is redundant.

   There are certainly cases in which the use of a Single-Type Signing
   Scheme with a long key effectivity period is a good choice, for
   example, where the costs and risks of compromise, and the costs and
   risks involved with having to perform an emergency roll, are low.

Top      ToC       Page 14 
3.4.  Cryptographic Considerations

3.4.1.  Signature Algorithm

   At the time of this writing, there are three types of signature
   algorithms that can be used in DNSSEC: RSA, Digital Signature
   Algorithm (DSA), and GOST.  Proposals for other algorithms are in the
   making.  All three are fully specified in many freely available
   documents and are widely considered to be patent-free.  The creation
   of signatures with RSA and DSA takes roughly the same time, but DSA
   is about ten times slower for signature verification.  Also note
   that, in the context of DNSSEC, DSA is limited to a maximum of
   1024-bit keys.

   We suggest the use of RSA/SHA-256 as the preferred signature
   algorithm and RSA/SHA-1 as an alternative.  Both have advantages and
   disadvantages.  RSA/SHA-1 has been deployed for many years, while
   RSA/SHA-256 has only begun to be deployed.  On the other hand, it is
   expected that if effective attacks on either algorithm appear, they
   will appear for RSA/SHA-1 first.  RSA/MD5 should not be considered
   for use because RSA/MD5 will very likely be the first common-use
   signature algorithm to be targeted for an effective attack.

   At the time of publication, it is known that the SHA-1 hash has
   cryptanalysis issues, and work is in progress to address them.  The
   use of public-key algorithms based on hashes stronger than SHA-1
   (e.g., SHA-256) is recommended, if these algorithms are available in
   implementations (see RFC 5702 [RFC5702] and RFC 4509 [RFC4509]).

   Also, at the time of publication, digital signature algorithms based
   on Elliptic Curve (EC) Cryptography with DNSSEC (GOST [RFC5933],
   Elliptic Curve Digital Signature Algorithm (ECDSA) [RFC6605]) are
   being standardized and implemented.  The use of EC has benefits in
   terms of size.  On the other hand, one has to balance that against
   the amount of validating resolver implementations that will not
   recognize EC signatures and thus treat the zone as insecure.  Beyond
   the observation of this tradeoff, we will not discuss this further.

3.4.2.  Key Sizes

   This section assumes RSA keys, as suggested in the previous section.

   DNSSEC signing keys should be large enough to avoid all known
   cryptographic attacks during the effectivity period of the key.  To
   date, despite huge efforts, no one has broken a regular 1024-bit key;
   in fact, the best completed attack is estimated to be the equivalent
   of a 700-bit key.  An attacker breaking a 1024-bit signing key would
   need to expend phenomenal amounts of networked computing power in a

Top      ToC       Page 15 
   way that would not be detected in order to break a single key.
   Because of this, it is estimated that most zones can safely use
   1024-bit keys for at least the next ten years.  (A 1024-bit
   asymmetric key has an approximate equivalent strength of a symmetric
   80-bit key.)

   Depending on local policy (e.g., owners of keys that are used as
   extremely high value trust anchors, or non-anchor keys that may be
   difficult to roll over), it may be advisable to use lengths longer
   than 1024 bits.  Typically, the next larger key size used is
   2048 bits, which has the approximate equivalent strength of a
   symmetric 112-bit key (RFC 3766 [RFC3766]).  Signing and verifying
   with a 2048-bit key takes longer than with a 1024-bit key.  The
   increase depends on software and hardware implementations, but public
   operations (such as verification) are about four times slower, while
   private operations (such as signing) are about eight times slower.

   Another way to decide on the size of a key to use is to remember that
   the effort it takes for an attacker to break a 1024-bit key is the
   same, regardless of how the key is used.  If an attacker has the
   capability of breaking a 1024-bit DNSSEC key, he also has the
   capability of breaking one of the many 1024-bit Transport Layer
   Security (TLS) [RFC5246] trust anchor keys that are currently
   installed in web browsers.  If the value of a DNSSEC key is lower to
   the attacker than the value of a TLS trust anchor, the attacker will
   use the resources to attack the latter.

   It is possible that there will be an unexpected improvement in the
   ability for attackers to break keys and that such an attack would
   make it feasible to break 1024-bit keys but not 2048-bit keys.  If
   such an improvement happens, it is likely that there will be a huge
   amount of publicity, particularly because of the large number of
   1024-bit TLS trust anchors built into popular web browsers.  At that
   time, all 1024-bit keys (both ones with parent zones and ones that
   are trust anchors) can be rolled over and replaced with larger keys.

   Earlier documents (including the previous version of this document)
   urged the use of longer keys in situations where a particular key was
   "heavily used".  That advice may have been true 15 years ago, but it
   is not true today when using RSA algorithms and keys of 1024 bits or
   higher.

Top      ToC       Page 16 
3.4.3.  Private Key Storage

   It is preferred that, where possible, zone private keys and the zone
   file master copy that is to be signed 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 RRSIG and NSEC/NSEC3 RRs.  Then the augmented file can
   be transferred to the master.

   When relying on dynamic update [RFC3007] or any other update
   mechanism that runs at a regular interval to manage a signed zone, be
   aware that at least one private key of the zone will have to reside
   on the master server or reside on an HSM to which the server has
   access.  This key is only as secure as the amount of exposure the
   server receives to unknown clients and on the level of security of
   the host.  Although not mandatory, one could administer a zone using
   a "hidden master" scheme to minimize the risk.  In this arrangement,
   the master name server that processes the updates is unavailable to
   general hosts on the Internet; it is not listed in the NS RRset.  The
   name servers in the NS RRset are able to receive zone updates through
   IXFR, AXFR, or an out-of-band distribution mechanism, possibly in
   combination with NOTIFY or another mechanism to trigger zone
   replication.

   The ideal situation is to have a one-way information flow to the
   network to avoid the possibility of tampering from the network.
   Keeping the zone master 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.

   The ideal situation may not be achievable because of economic
   tradeoffs between risks and costs.  For instance, keeping a zone file
   off-line is not practical and will increase the costs of operating a
   DNS zone.  So, in practice, the machines on which zone files are
   maintained will be connected to a network.  Operators are advised to
   take security measures to shield the master copy against unauthorized
   access in order to prevent modification of DNS data before it is
   signed.

Top      ToC       Page 17 
   Similarly, the choice for storing a private key in an HSM will be
   influenced by a tradeoff between various concerns:

   o  The risks that an unauthorized person has unnoticed read access to
      the private key.

   o  The remaining window of opportunity for the attacker.

   o  The economic impact of the possible attacks (for a TLD, that
      impact will typically be higher than for an individual user).

   o  The costs of rolling the (compromised) keys.  (The cost of rolling
      a ZSK is lowest, and the cost of rolling a KSK that is in wide use
      as a trust anchor is highest.)

   o  The costs of buying and maintaining an HSM.

   For dynamically updated secured zones [RFC3007], both the master copy
   and the private key that is used to update signatures on updated RRs
   will need to be on-line.

3.4.4.  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 4086 [RFC4086] and NIST SP 800-90A [NIST-SP-800-90A].  In
   particular, one should carefully assess whether the random number
   generator used during key generation adheres to these suggestions.
   Typically, HSMs tend to provide a good facility for key generation.

   Keys with a long effectivity period 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 preferred 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.4.5.  Differentiation for 'High-Level' Zones?

   An earlier version of this document (RFC 4641 [RFC4641]) made a
   differentiation between key lengths for KSKs used for zones that are
   high in the DNS hierarchy and those for KSKs used lower down in the
   hierarchy.

Top      ToC       Page 18 
   This distinction is now considered irrelevant.  Longer key lengths
   for keys higher in the hierarchy are not useful because the
   cryptographic guidance is that everyone should use keys that no one
   can break.  Also, it is impossible to judge which zones are more or
   less valuable to an attacker.  An attack can only take place if the
   key compromise goes unnoticed and the attacker can act as a man-in-
   the-middle (MITM).  For example, if example.com is compromised, and
   the attacker forges answers for somebank.example.com. and sends them
   out during an MITM, when the attack is discovered it will be simple
   to prove that example.com has been compromised, and the KSK will be
   rolled.



(page 18 continued on part 2)

Next RFC Part