Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6781

DNSSEC Operational Practices, Version 2

Pages: 71
Informational
Errata
Obsoletes:  4641
Part 1 of 4 – Pages 1 to 18
None   None   Next

Top   ToC   RFC6781 - 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.
Top   ToC   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   RFC6781 - 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   RFC6781 - 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   RFC6781 - 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   RFC6781 - 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   RFC6781 - 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   RFC6781 - 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   RFC6781 - 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   RFC6781 - 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   RFC6781 - 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   RFC6781 - 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   RFC6781 - 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   RFC6781 - 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   RFC6781 - 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   RFC6781 - 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   RFC6781 - 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   RFC6781 - 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 Section