INTERNET DRAFT Thierry Moreau Document: draft-moreau-dnsext-tak-req-00.txt CONNOTECH Category: Informational February, 2006 Expires: August, 2006 DNSKEY Trust Anchor Key Requirements Status of this Memo Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2006). IPR Disclosure Acknowledgment By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Abstract This draft attempts to fill a portion of the gap between DNSSEC deployment expectations and the lack of DNSSEC trust anchor key management solutions, protocol and procedural aspects. Specific requirements are stated at a level of abstraction that should accommodate solution alternatives to the issues of providing trust anchor keys to DNSSEC-aware resolvers, and rolling those keys. Nonetheless, the characteristics the DNSSEC protocols and the DNS operation contingencies do shape many of the requirements. Moreau Informational [page 1] Internet-Draft DNSSEC Trust Anchor Key Requirements February, 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Trust Anchor Key Life Cycle Requirements . . . . . . . . . . . . . 3 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Resolver-Side Trust Anchor Key Life Cycle . . . . . . . . . 4 2.3 Nameserver-Side Trust Anchor Key Life Cycle . . . . . . . . 6 3. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 DNS and DNSSEC Protocol Hosting . . . . . . . . . . . . . . 8 3.2 Deployment Agility . . . . . . . . . . . . . . . . . . . . . 8 3.3 Suitable Documentation . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Normative References . . . . . . . . . . . . . . . . . . . . . . . 9 6. Informative References . . . . . . . . . . . . . . . . . . . . . . 9 Annex A - Overview of DNSSEC Incremental Burden for Zone Managers . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 10 IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property . . . . . . . . . . . . . . . . . . . . . 11 Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . 11 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction In the operation of the DNSSEC protocols ([RFC4033], [RFC4034], [RFC4035]), the presence of at least one trust anchor key in a DNSSEC-aware resolver is a condition for the delivery of effective security services to applications. A trust anchor key is useful for DNSSEC "islands of security" and the root zone if and when it becomes DNSSEC-aware. To date, the IETF approach to the trust anchor key management issues has been to leave them out of scope of RFCs, perhaps due to the administrative aspects of DNS resolver trust configuration. As the DNSSEC protocols are expected to go out of the lab into the field, it is perhaps useful to formalize at least some aspects of the trust anchor key management. The need to roll (i.e. renew) DNSSEC signature keys applies to trust anchor keys like other types of cryptographic keys. Thus, a protocol interoperability question arises if an in-band, automated trust anchor key rollover mechanism is desirable. The present informational document states trust anchor key requirements in the context of DNSSEC deployment, assuming further Moreau Informational [page 2] Internet-Draft DNSSEC Trust Anchor Key Requirements February, 2006 standardization activities might turn these requirements into protocol and operational specifications. We whish our contribution to be closely related to the specifics of the DNSSEC application environment for the public key cryptography digital signature technology, e.g. not repeating general guidelines on cryptographic key life cycle management ([SP800-57-1]). DNS zone managers incur an incremental administrative burden when operating DNSSEC-aware nameservers and associated DNS registry functions. Trust anchor key requirements contribute to this incremental burden. In order to position the impact of trust anchor key on the overall DNSSEC workload, the latter is described in the informative annex A. 2. Trust Anchor Key Life Cycle Requirements 2.1 Overview In security protocols, a bird's eye view of exchanges is usually misleading since a given participant in an instance of the protocol experiences a sequence of events which may or may not comply to the bird's eye view, with only local significance. The same applies to the case of DNSSEC trust anchor key management, but with a strong asymmetry between a small number of nameservers and a huge number of resolvers, a unidirectional information flow (i.e. DNS query packets convey no state information to nameservers), and local determination by individual resolvers of public signature key trustworthiness. Thus, the system-wide or bird's eye view a DNSSEC trust anchor key life cycle is a unidirectional flow of data and trust bases, i.e. a) the performance of security procedures by zone managers, b) the partial reflection of this performance in DNS data broadcasted by authoritative nameservers, and c) a local determination of trust anchor key status by resolvers exposed to this broadcasted DNS data (or a portion of it). A DNSSEC trust anchor key is the public signature key associated with a DNS domain name, i.e. having a private key counterpart allegedly controlled by an organization authorized to publish DNS data for this domain name. The first basis of trust is a belief that the controlling organization will adhere to the generally agreed security principles for digital signatures by central organizations. ************ vvvvvvvvvvvvvvvvvvvv ************ Thus, a first requirement is the adoption of documented trust anchor key management procedures and protocols by the entity identified in the whois information for the root zone or an island of trust. ************ ==================== ************ Moreau Informational [page 3] Internet-Draft DNSSEC Trust Anchor Key Requirements February, 2006 2.2 Resolver-Side Trust Anchor Key Life Cycle For a DNS resolver, a trust anchor key implies a sense of assurance that a given public key is the legitimate one for a DNS zone name. A "sense of assurance" has obviously no direct digital representation. In a DNS resolver system, a trusted configuration space is needed to store trust anchor key information so that the DNS resolver can keep the status of trusted keys on behalf of the users. Although this is not a requirement for the key management scheme itself, it appears significant. ************ vvvvvvvvvvvvvvvvvvvv ************ The DNS resolver system support for trust anchor key management must include some form of local trusted configuration store. ************ ==================== ************ Cryptographic techniques, notably digital signatures, merely translate trust (or "sense of assurance") about a piece of data into trustworthiness about other data. The current DNSSEC specifications precisely define a trust anchor key as the public key at the end of a digital signature chain, i.e. a chain of trust translations. Accordingly, a trust anchor key inherits its trustworthiness either from "out-of-band" mechanisms or from recourse to cryptographic techniques that go beyond the current DNSSEC use of digital signatures. In practice, out-of-band trust anchor configuration is likely to occur with the installation of DNS resolver software from a trustworthy supplier or provisioning process, perhaps with procedural refinements for greater integrity assurance. Such opportunity for clean-out-of-the-box integrity assurance is deemed to be very rare later in a trust anchor life cycle. ************ vvvvvvvvvvvvvvvvvvvv ************ A trust anchor key management scheme may assume an opportunity for initializing a trusted configuration in a DNS resolver system at the very beginning of key life cycle for a given DNS resolver instance. ************ ==================== ************ By essence, trust is a lasting abstraction. When implemented as a digital signature public key configuration entry, the duration property contradicts the generally agreed recommendation to roll keys according to a schedule (cryptoperiod). For the record, here are the rationales for rolling keys in the first place: o cryptographic strength concerns, i.e. an old key might be cracked, o security operations concerns, i.e. over time, the uninterrupted confidentiality a production private key becomes less trustworthy, o survivability concerns to the extent that a scheduled renewal operation is like a rehearsal for an emergency private key recovery, or an alternative for it (e.g. if the private key Moreau Informational [page 4] Internet-Draft DNSSEC Trust Anchor Key Requirements February, 2006 breach has no practical impact or it is merely suspected). The conflicting goals of lasting trust and periodic rollover recommendation are compounded by the very limited feasibility of repeated out-of-band procedures and the huge number of DNS resolvers. This leads to an important requirement for trust anchor key management, paving the way to creative application of cryptographic mechanisms (i.e. beyond the current DNSSEC use of digital signatures) for the rollover operation at the resolver side. ************ vvvvvvvvvvvvvvvvvvvv ************ A trust anchor key management scheme must specify a trust anchor rollover operation that is automated to the greatest possible extent at the DNS resolver side. A rollover operation must allow a DNS resolver to obtain a new DNSSEC public signature key for the root zone or an island of trust, with cryptographic assurance of trustworthiness equivalent to the trustworthiness of the preceding public signature key for the same zone when this last key was first obtained by the DNS resolver (or could have been obtained). A rollover operation need not succeed at every attempt. ************ ==================== ************ The above requirement attempts to fit the real-world challenges of DNSSEC deployment, but it relies on cryptography ("with cryptographic assurance of") where it was previously stated that a trust anchor key is at the end of a chain of recursive reuse of cryptography. This must be acknowledged in a requirements statement. ************ vvvvvvvvvvvvvvvvvvvv ************ The "catastrophic failure mode" of trust anchor key operation specification is defined as the circumstances leading to, and consequences of, a failure of any of the cryptographic mechanisms relied upon for the rollover operation. A trust anchor key management scheme must disclose the details of its catastrophic failure mode. ************ ==================== ************ The above implicitly makes recovery from a catastrophic failure event a non-requirement. This complies with the view that a trust anchor key management solution for DNSSEC is merely an improvement over long-lasting trust anchors (i.e. no rollover) or an human- assisted rollover mechanism that is deemed to be error-prone with the vast majority of end-users. Up to now, emergency rollovers and key retirement were not addressed. It is a non-requirement for a DNS resolver to distinguish between an emergency rollover and a scheduled rollover: there would be no use of an emergency rollover signaling in a DNS resolver. Note that the above rollover operation requirement is stated with the assumption that a key is not breached when it is first made available to DNS resolvers. There is some level of abstraction in the requirement statements which should be lowered Moreau Informational [page 5] Internet-Draft DNSSEC Trust Anchor Key Requirements February, 2006 by actual scheme proposals. About key retirement, a DNS resolver is not in a position to systematically receive a notice of trust anchor key retirement when it occurs. However, if a DNS resolver detects that a trust anchor key has been retired, it should protect itself against key reuse attacks. ************ vvvvvvvvvvvvvvvvvvvv ************ If a trust anchor key management scheme allows a DNS resolver to detect that a trust anchor key has been retired, a compliant implementation of this scheme by a resolver must keep track of such key retirement events and protect itself against public key reuse attacks. ************ ==================== ************ 2.3 Nameserver-Side Trust Anchor Key Life Cycle On the nameserver side, the trust anchor key life cycle is controlled by the DNS zone manager organization which asserts the bind between the DNSSEC digital signature key and the zone name. This same self-assertion occurs for secure zones with a secure parent zone, but this time with a single receiving entity for the assertion (i.e. the parent zone manager) instead of the whole population of DNS resolvers. A first question arises in the event of a change in the zone manager controlling entity. If such a change occurs on a mutually agreed basis and a collaborative mode of operation, it should be transparent to third parties. In other cases, a disruptive change occurs in the zone manager controlling entity, so that any cryptographic key material used for DNSSEC, including for the support of a trust anchor key management scheme, is either lost, compromised, or suspect. For the root zone or an island of trust, it is a non-requirement to support such disruptive changes in the zone manager controlling entity. Many other aspects of a digital signature key life cycle for a signatory are applicable to the trust anchor key for a DNS zone manager. Some guidelines in this area may be reflected in the vital characteristics or features of a trust anchor key management scheme, e.g. if they are part of the definition for the scheme's "catastrophic failure mode" or if they provide data for the initial trust configuration in DNS resolvers. A digital signature key life cycle starts with the key pair generation and goes through the states depicted in the diagram below. Moreau Informational [page 6] Internet-Draft DNSSEC Trust Anchor Key Requirements February, 2006 key pair generation ------------------- | | | V | dormant state | ============= | | V V operational phase ================= | | | V | breached state | ============== | | V V retired state ============= It was mentioned that the opportunity to distribute out-of-band trusted information to DNS resolvers is limited in practice to the resolver installation time. This leads to a matching requirement for the nameserver side: ************ vvvvvvvvvvvvvvvvvvvv ************ A trust anchor key management scheme must disclose to which extent it is dependent on initial out-of-band distribution of trusted configuration material from a zone manager to DNS resolvers. ************ ==================== ************ We can now state a few more requirements for trust anchor key management scheme. These are derived from a general understanding of the security issues in a signature key life cycle. ************ vvvvvvvvvvvvvvvvvvvv ************ A trust anchor key management scheme must allow the operational phase of a trust anchor key to begin before the retired state of a preceding trust anchor key. ************ ==================== ************ ************ vvvvvvvvvvvvvvvvvvvv ************ A trust anchor key management scheme must include provisions allowing a DNS zone manager to retire a trust anchor key in a way that allows DNS resolvers to notice the key retirement. ************ ==================== ************ Note that the above requirement is partially a wishful thinking requirement since it does not state any guideline on the likelihood or ease with which DNS resolvers would notice key retirement. ************ vvvvvvvvvvvvvvvvvvvv ************ The DNS zone manager should make prudent application of generally agreed security principles throughout the DNSSEC digital signature Moreau Informational [page 7] Internet-Draft DNSSEC Trust Anchor Key Requirements February, 2006 key life cycle. A trust anchor key management scheme must disclose which aspects of these security principles are needed for the avoidance of the scheme's critical failure mode. ************ ==================== ************ 3. Other Issues 3.1 DNS and DNSSEC Protocol Hosting A DNSSEC trust anchor key management scheme should adhere to the design principles and detailed protocol specifications of the DNS and DNSSEC protocols. The assessment of a scheme's compliance to this recommendation is a matter of public review, ease of integration into existing DNS and DNSSEC tools and servers, and quality of supporting documentation. The performance impact of a scheme falls into this general recommendation. Ideally, the DNS resolver procedures should restrict the occurrence of trust-anchor-key-specific queries to circumstances where a change in a trust anchor key status is likely to occur. For DNS answer sizes, the scheme's impact should be estimated notable for incremental response sizes for queries not directly related to trust anchor key management. 3.2 Deployment Agility The DNSSEC deployment can not occur at once for the whole Internet. Islands of trust are deemed to appear while parent zones are not yet secured and ready to accept secure delegations. This implies a need for graceful transition from an island of trust to a secure zone with a secure parent. During this transition, some DNS resolvers might view the zone still as an island of security, while others would be unaware that the zone was ever an island of security. Also, it was mentioned that a DNS zone manager may revert to a DNSSEC-oblivious mode of operation after the zone has been made DNSSEC-aware. This course of action is possible for the parent zone of an ordinary secured zone. This opens the door to a normal secured zone becoming an island of security following a decision made by a third party. So the graceful transition in the reverse direction from the preceding paragraph should be supported as well by a trust anchor key management scheme. Specific requirements in the area of DNSSEC deployment agility might be stated if a formal DNSSEC deployment roadmap is brought up. Other issues of deployment agility may address the concurrent existence of multiple trust anchor key management schemes for a given zone, or the presence of private trust arrangements in the public DNS, neither of which should be prevented by a particular scheme. Moreau Informational [page 8] Internet-Draft DNSSEC Trust Anchor Key Requirements February, 2006 3.3 Suitable Documentation Documentation guidelines may be developed. For instance, a mandated documentation of cryptoperiod management facilities built in a scheme may be deserved despite the absence of requirements expressed as a cryptoperiod implementation issue (indirectly provided by the required ability to retire a key and the required overlap between the operational phases of keys). 4. Security Considerations The present document is wholly about security, but incompletely describes the security downgrade caused by the DNS protocol environment, e.g. the inability for a zone manager to send a specific message to DNS resolvers. Specifications derived from the present document should be throughly reviewed for a clear statement of security goals and limitations. 5. Normative References [RFC4033] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005 [RFC4034] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005 [RFC4035] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005 6. Informative Reference [SP800-57-1] Elaine Barker, William Barker, William Burr, William Polk, and Miles Smid, "Recommendation for Key Management - Part 1: General", NIST Special Publication 800-57 part 1, August, 2005 Moreau Informational [page 9] Internet-Draft DNSSEC Trust Anchor Key Requirements February, 2006 Annex A - Overview of DNSSEC Incremental Burden for Zone Managers This annex gives a brief overview of the DNSSEC incremental burden for zone managers. It is intended to prevent a magnifying glass effect that could taint the trust anchor key management as "the" show stopper for DNSSEC deployment. In fact, once the open questions raised in the body of the present document are answered, the zone manager procedures for trust anchor key management should be a small portion of the overall DNSSEC incremental burden. Ensuring stable operations of authoritative nameservers. DNSSEC incremental burden: o monitoring the performance impact of DNSSEC deployment, o revision of arrangements for secondary nameserver operations, o possible DNS software upgrade for continued DNSSEC compliance. Maintaining accurate records in zone file contents, and whois information. DNSSEC incremental burden: o revision of procedures for authenticating change requests, o for secure delegations, use of secure provisioning tools, o implementing zone file signature procedures with adequate controls of DNSSEC private signature keys. For zones other than the root zone (and other than islands of trust once DNSSEC is deployed), the DNS zone name registration with the parent must be maintained. DNSSEC incremental burden: o use the secure provisioning tools implemented by the parent zone for maintaining the parental DS delegation. Finally, for the root zone and islands of trust, the DNSSEC incremental burden includes the procedures for trust anchor key management to be developed from the requirements stated in the body of this document. Author's Address Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc, Canada Tel.: +1-514-385-5691 e-mail: thierry.moreau@connotech.com Moreau Informational [page 10] Internet-Draft DNSSEC Trust Anchor Key Requirements February, 2006 IPR Notices Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Copyright Notice Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Moreau Informational [page 11]