RFC 6781
DNSSEC Operational Practices, Version 2
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 2Abstract
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.
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
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
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 ......................701. 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.
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.
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.
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?
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
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.
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
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
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
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.
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
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.
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.
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.
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)
