RFC 4986

Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover

📅 published August 2007, from ietf

📜 Quick facts first, bestie! This is RFC 4986, and it's an Informational doc from August 2007. It was written by H. Eland (Afilias Limited), R. Mundy (SPARTA, Inc.), S. Crocker (Shinkuro Inc.), and S. Krishnaswamy (SPARTA, Inc.), all sitting in the Network Working Group. It doesn't obsolete or update anything, since the header lists nothing for either. 💅

Status of This Memo ✨

okay so this memo is here to give information to the Internet community. It's not a standard of any kind 🙅‍♀️ and distribution is unlimited, so share away 💖

Abstract 🌸

every DNS security-aware resolver needs at least one Trust Anchor to validate responses from DNS signed zones, and for different reasons most of them are expected to have several. Manually keeping track of Trust Anchors is doable for some setups, but lots of operations are going to need automated ways to update them. This doc lists the requirements that an automated DNS Trust Anchor rollover solution has to meet for security-aware DNS resolvers. It's giving checklist energy 📋🦋

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.  Background  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . . . 6
  5.1.  Scalability . . . . . . . . . . . . . . . . . . . . . . . . 6
  5.2.  No Known Intellectual Property Encumbrance  . . . . . . . . 6
  5.3.  General Applicability . . . . . . . . . . . . . . . . . . . 7
  5.4.  Support Private Networks  . . . . . . . . . . . . . . . . . 7
  5.5.  Detection of Stale Trust Anchors  . . . . . . . . . . . . . 7
  5.6.  Manual Operations Permitted . . . . . . . . . . . . . . . . 7
  5.7.  Planned and Unplanned Rollovers . . . . . . . . . . . . . . 7
  5.8.  Timeliness  . . . . . . . . . . . . . . . . . . . . . . . . 8
  5.9.  High Availability . . . . . . . . . . . . . . . . . . . . . 8
  5.10. New RR Types  . . . . . . . . . . . . . . . . . . . . . . . 8
  5.11. Support for Trust Anchor Maintenance Operations . . . . . . 8
  5.12. Recovery from Compromise  . . . . . . . . . . . . . . . . . 8
  5.13. Non-Degrading Trust . . . . . . . . . . . . . . . . . . . . 8
6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 9
7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 9
8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 9

1. Introduction 💫

okay so DNSSEC, which is written up in [2], [3], and [4], adds new records and protocol changes to DNS. That's what lets security-aware resolvers validate DNS Resource Records (RRs) using one or more Trust Anchors they already hold 🔐

security-aware resolvers have to get their Trust Anchors in a trustworthy way first, so the Trust Anchors are correct and valid. There are a bunch of ways to do that initial step, but the details are out of scope for this doc. Once an operator has the Trust Anchors, typing them into their resolvers is often a manual job 🙈

For some setups, managing Trust Anchors by hand could totally work. But lots of environments need a more automated, specification-based way to update and manage them. This doc gives a list of requirements that anyone can use to measure any proposed automated Trust Anchor rollover mechanism in a consistent way 📏✨

2. Terminology 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].

the RFC 2119 words in the requirements are there to describe each requirement without any wiggle room 🤌 If you have to trade off between conflicting requirements when picking a solution, the one with MUST language wins over anything with SHOULD, MAY, or RECOMMENDED language. Trade-offs between requirements that both use RFC 2119 language can still happen 💅

3. Background 🌈

DNS resolvers need one or more starting points to get DNS answers. For stub resolvers, those starting points are usually the IP addresses of one or more recursive name servers. For recursive name servers, they're usually the IP addresses of DNS Root name servers. security-aware resolvers need starting points too, to build the authenticated chain for validating a signed DNS response. But instead of IP addresses, DNSSEC has each resolver trust one or more DNSKEY RRs or DS RRs as its starting point. Each of those starting points is called a Trust Anchor 👑

Here's the tea 🫖: DNSKEY RRs and DS RRs are not Trust Anchors just because the signed zone operator created them, and they're not Trust Anchors just because they're published in the signed zone either. A DNSKEY RR or DS RR only becomes a Trust Anchor when the operator of a security-aware resolver decides that its public key or hash will be used as one. So the signed zone operator who made and/or published these RRs might not even know whether any of their DNSKEY RRs or DS RRs are being used as Trust Anchors by security-aware resolvers. The obvious exception is the DNSKEY RRs for the Root Zone, which lots of security-aware resolvers use as Trust Anchors. For various reasons, though, DNSKEY RRs or DS RRs from zones other than Root can be used as Trust Anchors by resolver operators too. That means the resolver operator is the one responsible for making sure the DNSKEY and/or DS RRs they picked as Trust Anchors are valid at the moment the resolver uses them as the starting point for building the authentication chain to validate a signed DNS response 🫶

When operators of security-aware resolvers pick one or more Trust Anchors, they also need to figure out how they'll make sure they're using valid RRs, and how they'll know when RRs used as Trust Anchors should be replaced or removed. Early adopters of DNS signed zones published info about how and when their DNSKEY and/or DS RRs would change, so resolver operators could manually swap Trust Anchors at the right time. But that manual approach won't scale 😭 which is exactly why we need an automated, specification-based approach to rolling over Trust Anchors for security-aware resolvers 🚀

4. Definitions 🦋

This document uses the definitions in RFC 4033, section 2, plus the following extra definitions:

Trust Anchor: From RFC 4033, "A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A validating security-aware resolver uses this public key or hash as a starting point for building the authentication chain to a signed DNS response." On top of that, a DNSKEY RR or DS RR is tied to exactly one point in the DNS hierarchy, meaning one DNS zone. Multiple Trust Anchors MAY be associated with each DNS zone and MAY be held by any number of security-aware resolvers. Security-aware resolvers MAY have Trust Anchors from multiple DNS zones. The people running security-aware resolvers are responsible for deciding which RRs that resolver will use as Trust Anchors 🎯

Initial Trust Relationship: Operators of security-aware resolvers must make sure they get any Trust Anchors in a trustworthy way. For example, you could check the Root Zone DNSKEY RR(s) by comparing what the operator thinks are the Root Trust Anchor(s) against several 'well-known' sources, like the IANA web site, the DNS published Root Zone, and the public key printed in well-known hard-copy forms. For other Trust Anchors, the operator must make sure the DNSKEY and/or DS RRs are accurate and valid before naming them Trust Anchors. That could come from a mix of technical, procedural, and contractual relationships, or from other existing trust relationships outside the current DNS protocol 🤝

Trust Anchor Distribution: The method or methods used to pass the DNSKEY and/or DS RR(s) from the signed zone operator to the security-aware resolver operator. The method or methods MUST be deemed sufficiently trustworthy by the operator of the security-aware resolver, so the source authenticity and integrity of the new RRs are assured and the Initial Trust Relationship needed to designate those RRs as Trust Anchors is kept intact 📦

Trust Anchor Maintenance: Any change in a validating security-aware resolver that adds a new Trust Anchor, deletes an existing Trust Anchor, or replaces an existing Trust Anchor with another one. The change might be done by hand or in some automated way. The people running the security-aware resolver are responsible for setting up policies and procedures that make sure a sufficient Initial Trust Relationship is in place before adding Trust Anchors for a particular DNS zone to their resolver configuration 🛠️

Trust Anchor Revocation and Removal: The invalidation of a particular Trust Anchor that happens when the signed zone operator revokes or removes a DNSKEY RR or DS RR that some security-aware resolver is using as a Trust Anchor. A zone administrator might invalidate more than one RR at a time, so it MUST be clear to both the zone administrator and the security-aware resolver exactly which RR(s) were revoked or removed, so the right Trust Anchor or Trust Anchors get removed 🗑️

⚠️ Mixing up which RR got revoked is how you end up deleting the wrong Trust Anchor, so spell out exactly which RR(s) are going away! 💀

Trust Anchor Rollover: The method or methods needed to securely replace one or several Trust Anchors held by security-aware resolvers. Trust Anchor Rollover should be considered a subset of Trust Anchor Maintenance. 🔄

Normal or Pre-Scheduled Trust Anchor Rollover: The operator of a DNSSEC signed zone has issued a new DNSKEY and/or DS RR(s) as part of a regular operational routine 📅

Emergency or Non-Scheduled Trust Anchor Rollover: The operator of a signed zone has issued a new DNSKEY and/or DS RR(s) as part of an exceptional event 🚨

Emergency Trust Anchor Revocation: The operator of a signed zone wants to say that the current DNSKEY and/or DS RR(s) are no longer valid because of an exceptional event 🙅‍♀️

5. Requirements 🍓

Here are the requirements for DNSSEC automated specification-based Trust Anchor Rollover. The detailed list picks up in the next part, so stay tuned, bestie 💜

5.1. Scalability 🌸

okay so the automated Trust Anchor Rollover solution MUST be capable of scaling to Internet-wide usage 🌍. The probable largest number of security-aware resolvers that need to roll over a Trust Anchor will be the ones using the public key(s) for the Root Zone as their Trust Anchor(s). That number could get absolutely huge if a bunch of apps have security-aware resolvers baked right in 😭.

The automated Trust Anchor Rollover solution MUST be able to support Trust Anchors for multiple zones, and multiple Trust Anchors for each DNS zone 🦋. Nobody knows for certain how many Trust Anchors one validating security-aware resolver might have configured right now 🤷‍♀️. Usually it's under 20, but it could even be as high as one thousand 💀.

5.2. No Known Intellectual Property Encumbrance 💜

Since trust anchor rollover is probably going to be "mandatory-to-implement" 📋, section 8 of [5] says the technical solution we pick must not be known to be encumbered, or it has to be available under royalty-free terms 🙅‍♀️.

So when this doc says "royalty-free," it means a worldwide, irrevocable, perpetual right to use, without fee, in commerce or otherwise 💸. "Use" covers descriptions of algorithms, distribution and/or use of hardware implementations, distribution and/or use of software systems in source and/or binary form, in all DNS or DNSSEC applications including registry, registrar, domain name service including authority, recursion, caching, forwarding, stub resolver, or similar 🧚.

The short version is that no implementor, distributor, or operator of the technology picked for trust anchor management shall be expected or required to pay any fee to any IPR holder for the right to implement, distribute, or operate a system which includes the chosen mandatory-to-implement solution 🎀.

5.3. General Applicability 🌈

The solution MUST provide the capability to maintain Trust Anchors in security-aware resolvers for any and all DNS zones ✨.

5.4. Support Private Networks 🏡

The solution MUST support private networks with their own DNS hierarchy 🌲.

5.5. Detection of Stale Trust Anchors 🕰️

The Trust Anchor Rollover solution MUST allow a validating security-aware resolver to be able to detect if the DNSKEY and/or DS RR(s) can no longer be updated given the current set of actual trust-anchors. In these cases, the resolver should inform the operator of the need to reestablish initial trust 🚨.

5.6. Manual Operations Permitted 🛠️

The operator of a security-aware resolver may choose manual or automated rollover, but the rollover protocol must allow the implementation to support both automated and manual Trust Anchor Maintenance operations. Implementation of the rollover protocol is likely to be mandatory, but that's out of scope for this requirements document 🙃.

5.7. Planned and Unplanned Rollovers 📅

The solution MUST permit both planned (pre-scheduled) and unplanned (non-scheduled) rollover of Trust Anchors. Support for providing an Initial Trust Relationship is OPTIONAL 🗓️.

5.8. Timeliness ⏰

Resource Records used as Trust Anchors SHOULD be able to be distributed to security-aware resolvers in a timely manner.

Security-aware resolvers need to grab new DNSKEY and/or DS RRs being used as Trust Anchors for a zone, and drop revoked ones, so that no old RR is used as a Trust Anchor for long after the zone issues new or revokes existing RRs 🏃‍♀️💨.

5.9. High Availability 🟢

Information about the zone administrator's view of the state of Resource Records used as Trust Anchors SHOULD be available in a trustworthy manner at all times to security-aware resolvers. Information about Resource Records that a zone administrator has invalidated and that are known to be used as Trust Anchors should be available in a trustworthy manner for a reasonable length of time 🫶.

5.10. New RR Types 🆕

If a Trust Anchor Rollover solution requires new RR types or protocol modifications, this should be considered in the evaluation of solutions. The working group needs to determine whether such changes are a good thing or a bad thing or something else 🤔.

5.11. Support for Trust Anchor Maintenance Operations 🧩

The Trust Anchor Rollover solution MUST support operations that allow a validating security-aware resolver to add a new Trust Anchor, delete an existing Trust Anchor, or replace an existing Trust Anchor with another 💅.

5.12. Recovery from Compromise 🚑

The Trust Anchor Rollover solution MUST allow a security-aware resolver to be able to recover from the compromise of any of its configured Trust Anchors for a zone so long as at least one other key, which is known to have not been compromised, is configured as a Trust Anchor for that same zone at that resolver 🦸‍♀️.

5.13. Non-Degrading Trust 💎

The Trust Anchor Rollover solution MUST provide sufficient means to ensure authenticity and integrity so that the existing trust relation does not degrade by performing the rollover ✨.

6. Security Considerations 🔐

Serious moment, bestie: this document defines overall requirements for an automated specification-based Trust Anchor Rollover solution for security-aware resolvers, but it specifically does not define the security mechanisms needed to meet these requirements 🚨.

7. Acknowledgements 🫶

This document reflects the majority opinion of the DNSEXT Working Group members on the topic of requirements related to DNSSEC trust anchor rollover. The contributions made by various members of the working group to improve the readability and style of this document are graciously acknowledged 💖.

8. Normative References 📚

  • [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
  • [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
  • [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
  • [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
  • [5] Bradner, S., "Intellectual Property Rights in IETF Technology", RFC 3979, March 2005.

Authors' Addresses 🖋️

Howard Eland
Afilias Limited
300 Welsh Road
Building 3, Suite 105
Horsham, PA  19044
USA

EMail: heland@afilias.info


Russ Mundy
SPARTA, Inc.
7110 Samuel Morse Dr.
Columbia, MD  21046
USA

EMail: mundy@sparta.com


Steve Crocker
Shinkuro Inc.
1025 Vermont Ave, Suite 820
Washington, DC  20005
USA

EMail: steve@shinkuro.com


Suresh Krishnaswamy
SPARTA, Inc.
7110 Samuel Morse Dr.
Columbia, MD  21046
USA

EMail: suresh@sparta.com

Copyright (C) The IETF Trust (2007).

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.

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, THE IETF TRUST 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.

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 procedures with respect to rights in RFC 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. 💜✨

📦 where this page comes from