RFC 6841

A Framework for DNSSEC Policies and DNSSEC Practice Statements

📅 published January 2013, from ietf

RFC 6841: A Framework for DNSSEC Policies and DNSSEC Practice Statements 💖

Okay bestie, let's get into it! 🦋 This is RFC 6841, an Informational doc from January 2013. Its authors are F. Ljunggren (Kirei AB), AM. Eklund Lowinder (.SE), and T. Okubo (ICANN). It's published under ISSN 2070-1721, and it doesn't obsolete or update any other RFCs. Iconic energy! ✨

Abstract ✨

So this doc gives you a framework to help people write DNSSEC Policies and DNSSEC Practice Statements 📝. Think domain managers and zone operators, both at the top level and the second level, who run a DNS zone with Security Extensions turned on. 💅

The big thing is that the framework gives you a full list of topics you should think about putting into a DNSSEC Policy definition and a Practice Statement. Main character list, honestly. 👑

Status of This Memo 🌸

Okay so this document is not an Internet Standards Track spec. It's just published for informational purposes, no cap. 🫶

It's still a product of the IETF, and it reflects the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, though. You can read Section 2 of RFC 5741 for that. 🎀

If you want the current status, any errata, or a way to send feedback, head to http://www.rfc-editor.org/info/rfc6841 ✨

Copyright (c) 2013 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) as they stood on the publication date. Please actually read these, because they lay out your rights and restrictions for this doc. 🙈

If you extract Code Components from this document, they have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They also come without warranty, as the Simplified BSD License describes. ⭐

Table of Contents 📚

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Background . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Purpose  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.3.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  DNSSEC Policy  . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  DNSSEC Practice Statement  . . . . . . . . . . . . . . . .  7
     3.3.  Relationship between DNSSEC Policy and Practice
           Statement  . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.4.  Set of Provisions  . . . . . . . . . . . . . . . . . . . .  9
   4.  Contents of a Set of Provisions  . . . . . . . . . . . . . . . 10
     4.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . 10
     4.2.  Publication and Repositories . . . . . . . . . . . . . . . 11
     4.3.  Operational Requirements . . . . . . . . . . . . . . . . . 12
     4.4.  Facility, Management, and Operational Controls . . . . . . 13
     4.5.  Technical Security Controls  . . . . . . . . . . . . . . . 17
     4.6.  Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 20
     4.7.  Compliance Audit . . . . . . . . . . . . . . . . . . . . . 22
     4.8.  Legal Matters  . . . . . . . . . . . . . . . . . . . . . . 23
   5.  Outline of a Set of Provisions . . . . . . . . . . . . . . . . 23
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 26
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 26

1. Introduction ✨

1.1. Background 🍓

Okay so the Domain Name System (DNS) was not originally built with strong security to guarantee the integrity and authenticity of its data. 🙈 Over the years, a bunch of vulnerabilities have popped up that threaten how reliable and trustworthy the system is. Not ideal!

Enter the Domain Name System Security Extensions (DNSSEC, [RFC4033], [RFC4034], [RFC4035]) 🔐. They fix this by using public key cryptography to add data origin authentication, data integrity verification, and authenticated denial-of-existence to the DNS. Basically, DNSSEC gives software a way to check where DNS data came from and confirm it hasn't been changed in transit or by any middlemen. Slay. 💅

Now, if stakeholders want to judge how strong and secure a DNSSEC chain of trust is, an entity running a DNSSEC-enabled zone can publish a DNSSEC Practice Statement (DPS) 📜. This explains the critical security controls and procedures that matter when you're checking whether the system can be trusted. The DPS can also list any DNSSEC Policies (DPs) it supports, and explain how it meets their requirements. 🫶

The DP and DPS aren't really aimed at the users who rely on signed DNS responses (the "relying parties") 👀. Their main audience is other stakeholders in the DNS infrastructure, which can include bodies like regulatory authorities. 👑

Even though this doc is heavily inspired by the "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework" [RFC3647], and big chunks are drawn straight from it 🌸, the properties and structure of the DNSSEC trust model are fundamentally different from X.509 Public Key Infrastructure (PKI). Different vibes entirely. 🦋

1.2. Purpose 🎀

This doc has two goals, bestie. 💖 First, it explains what a DNSSEC Policy (DP) and a DNSSEC Practice Statement (DPS) are, and how the two relate to each other. Second, it gives writers a framework to encourage and help them create Policies and Practice Statements that are consistent and comparable. The framework points out the elements you should think about when putting together a DP or a DPS. ✨

It does not define any particular Policy or Practice Statement, and it doesn't give legal advice or recommendations about what goes in them. Not its job! ⚖️

1.3. Scope 🧚

The scope here is limited to the topics that can be covered in a DP or a DPS. It doesn't dig into the specific details that could go in either one. What it does do is describe the kinds of information you should consider including. 📝

Think of this framework as a checklist of factors you ought to take into account before deploying DNSSEC, and as an outline for building an operational practices disclosure document. 🌈 It's all about the topics that get affected when DNSSEC is introduced into a zone. Other stuff, like how name servers and registry systems operate, is out of scope, sorry not sorry. 🙅‍♀️ The framework is mainly for Top-Level Domain (TLD) managers and organizations that provide registry services. But high-value domain holders can use it too, as a high-level checklist for DNSSEC readiness. 💜

Last thing: this doc assumes you already know the general concepts of DNS, DNSSEC, and PKI. No pressure, but you're gonna need them! 🥰

2. Definitions 💅

okay so this section is the glossary bestie, and it's lowkey where all the vocab lives 📚 we're using these terms all the way through the doc so let's get them down 🫶

Audit logs: these are control evidence records that prove the integrity of processes 🔍 they can come from DNS and DNSSEC-related systems, get supplied by the surrounding facility, or be pulled from manually generated, non-electronic documentation 📝 the internal and/or external auditors will examine them.

Activation data: data values (not keys!) that are needed to operate the cryptographic modules, which protect the keys from unauthorized use 🔐

Chain of trust: a hierarchical structure of trust made up of DNS keys, signatures, and delegation signer records 🔗 when you validate them in a series, they can prove the authenticity of the last element in the chain, as long as the first element is trusted 💖 usually that first element is a trust anchor.

Compromise (key compromise): key compromise happens when the private component of a signing key is lost, stolen, exposed, modified, or used in an unauthorized manner 😭 and here's the strict part: even a suspicion that one of these has happened counts as key compromise 🙈

DNS: the Domain Name System (DNS) is a hierarchical global naming catalog for computers, services, or any resource connected to the Internet 🌐 it's giving phonebook energy ✨

DNS zone: a portion of the global Domain Name System (DNS) namespace that has had its administrative responsibility delegated 🍓

DNSSEC: DNS Security Extensions (DNSSEC) is a set of IETF specifications [RFC4033] [RFC4034] [RFC4035] that use public key cryptography to add data origin authentication, data integrity verification, and authenticated denial of existence capabilities to DNS 🔥 it's the security glow-up for DNS, periodt 💅

DNSSEC Policy: a DNSSEC Policy (DP) sets forth the security requirements and standards that have to be implemented for a DNSSEC-signed zone 📜

DNSSEC Practice Statement: a DNSSEC Practice Statement (DPS) is a practices disclosure document 🧾 it may support the DNSSEC Policy (if one exists) as a supplemental document, and it states, at a high level, how the management of a given zone implements procedures and controls 🎀

Key rollover: an operational process for changing one of the DNSSEC keys that signs a zone, done by distributing public keys in a trusted manner 🦋

Multi-person control: a security concept that spreads the authority of an operation across multiple persons, so a single authorized individual can't cause threats on their own 👑 for example, a key recovery function may need some number of authorized individuals (m) out of the (n) people who each got a portion of the recovery key 🧩 they combine their key fragments before key recovery can happen 🫶

PKI: Public Key Infrastructure (PKI) is a concept that uses asymmetric cryptography to give a system integrity, authentication, and confidentiality 🔐 it does this by distributing public keys in a trusted manner ✨

Policy authority: the body responsible for setting and administering a DNSSEC Policy, and for deciding whether a DPS is suitable for that Policy 💜

Relying party: an entity that relies on a signed response from the DNS 🥰

Repository: a location on the Internet that stores DP, DPS, trust anchors, and other related information that should be kept public 🌈

Security posture: a security posture is an indicator of how secure an entity is and how secure it should be 🛡️ it's the result of an adequate threat model and risk assessment 🧠

Separation of duties: a security concept that limits the influence of a single person by splitting up roles and responsibilities 🙅‍♀️

Signing key: the private component of an asymmetric key pair, used to sign resource records within the zone 🖋️ the other component, the public key, is used for signature validation 🌸

TLD: a Top-Level Domain (TLD) is one of the domains at the highest level below the root in the DNS hierarchy 🌳

Trust anchor: the public portion of a key pair, and the authoritative entity used to authenticate the first element in a chain of trust 🦋

3. Concepts 🧚

this section breaks down the concepts of a DNSSEC Policy and a DNSSEC Practice Statement 💖 other related concepts show up too, so stay tuned 👀

3.1. DNSSEC Policy

a DNSSEC Policy (DP) sets forth requirements that are appropriate for a specified level of assurance 📋 for example, a DP may cover all the topics of this framework, each with its own set of security requirements, possibly grouped by impact 🎯 going from medium to high levels of assurance would mean increasing security requirements and increasing levels of assurance, so it's a whole level-up situation 🎮

a DP also gives a basis for an audit, accreditation, or some other assessment of an entity ✅ each entity can be assessed against one or more DPs that it claims to implement 💅

3.2. DNSSEC Practice Statement

most zone managers using DNSSEC won't need to write a thorough and detailed statement of practices 🙃 for example, a registrant might be the sole relying party for its own zone, so it already knows how trustworthy its services are 💁‍♀️ in other cases, a zone manager may offer registration services at a very low level of assurance, where the domain names being secured only pose marginal risks if compromised 🌷 publishing a DPS matters most for entities operating a zone with a significant number of delegations to other entities 📣

a DNSSEC Practice Statement (DPS) should contain information that is relevant to the stakeholders of the relevant zone(s) 🫶 since those generally include the Internet community, it should not contain information that could be considered sensitive details of an entity's operations 🤫

a DNSSEC Practice Statement may identify a supported DP 🎀 a relying party can then use that to evaluate the trustworthiness of any digital signatures verified with the public key of that entity 🔍

3.3. Relationship between DNSSEC Policy and Practice Statement

okay this is the big compare-and-contrast moment 🧁 a DNSSEC Policy and a DNSSEC Practice Statement cover the same set of topics that stakeholders care about, in terms of how much confidence they have in the zone's security posture 💜 the main difference is the focus of their provisions ✨ a Policy sets forth the requirements and standards that have to be implemented for a DNSSEC-signed zone, and it may be used to communicate requirements that complying parties must meet 📜 that also means it can help determine or establish equivalency between policies tied to different zones 🤝 a Practice Statement, by contrast, describes how a zone operator (and possibly other participants in managing that zone) implements procedures and controls to meet the requirements of applicable Policies 🛠️ in other words, the Policy says what needs to be done, and the Practice Statement says what is being done 💅

there's another difference in coverage 🌈 a Policy may apply to multiple organizations or multiple zones 🏢 a Practice Statement, on the other hand, would usually apply only to a single zone operator or a single organization, since it describes the actual controls in place that meet the requirements of applicable Policy 🦋

here's an example 🎀 a TLD manager or regulatory authority may define requirements in a Policy for operating one or more zones 👑 the Policy will be a broad statement of the general requirements for managing the zone 🌸 a zone operator may be required to write its own Practice Statement to support the Policy, explaining how it meets the requirements of the Policy 📝 or, if a zone operator is also the manager of that zone and isn't governed by any external Policy, it may still choose to disclose its operational practices by publishing a DPS 🧁 it might do this for transparency and to gain community trust in its operations 🫶

one more thing: a Policy and a Practice Statement differ in how much detail they give ✨ although there may be variations, a Practice Statement describes procedures and controls, so it will usually be more detailed than a Policy, which provides general principles 💖

the main differences between a Policy and a Practice Statement can be summarized like this 🌟

(a) Operation of a DNS zone with DNSSEC may be governed by a Policy that establishes requirements stating what the entity operating that zone must do 📜 an entity can use a Practice Statement to disclose how it meets the requirements of a Policy, or how it has implemented critical processes and controls when there's no controlling Policy 🧾

(b) a Policy may serve the purpose of establishing a common basis of trusted operation across a set of zones in the DNS hierarchy 🌳 a Practice Statement, by contrast, is a statement of a single zone operator or organization 🏠

(c) a Practice Statement is generally more detailed than a Policy 🔎 it specifies how the zone operator or organization implements critical processes and controls, and how the entity meets any requirements specified in the one or more Policies under which it operates DNSSEC 💜

3.4. Set of Provisions

okay so a set of provisions is basically a bundle of Policy requirements or Practice Statements 🧚 It can use the approach in this framework by covering the topics in Section 5 below, and those topics get the full breakdown in Section 4 💖

A Policy can be one single set of provisions ✨ A Practice Statement can also be one set of provisions, where each piece addresses the requirements of one or more Policies 🎀 Or it can be a set of provisions that doesn't reference any particular policy at all, and instead lays out the self-imposed controls the stakeholders can count on 🫶 For example, a Practice Statement could be a mix of the following:

  • (a) a list of Policies supported by the DPS;
  • (b) for each Policy in (a), a set of provisions that fills in the details the policy didn't stipulate or left to the implementer's discretion. These statements show how this particular Practice Statement carries out the requirements of that particular Policy; or
  • (c) a set of provisions with statements about the DNSSEC operations practices, independent of any Policy 💅

The statements in (b) can augment or refine the stipulations of an applicable Policy, but generally they can't clash with those stipulations 😭 That said, a Policy authority is allowed to make exceptions in certain cases, because certain compensating controls the entity disclosed in its Practice Statement can give it a level of assurance equal to full compliance with the policy 🦋

The framework lays out what goes into a set of provisions through eight primary components, like so:

  1. Introduction
  2. Publication and Repositories
  3. Operational Requirements
  4. Facility, Management, and Operational Controls
  5. Technical Security Controls
  6. Zone Signing
  7. Compliance Audit
  8. Legal Matters

Policy authorities can use this framework to write DNSSEC Policies, and zone operators can use it to write DNSSEC Practice Statements 🌈 Having everything in the same structure makes it way easier to compare with the matching documents of other zones, which is honestly so satisfying 🍓

4. Contents of a Set of Provisions ✨

This section walks through what goes inside a set of provisions. Check Section 5 for the complete outline 🎀

Drafters of DPSs that conform to this framework are allowed to add extra levels of subcomponents below the ones described here, to fit specific needs 💜 All components listed in Section 5 should be present, but drafters can leave components empty and just write "no stipulation" if they need to 🙈

4.1. Introduction

This component identifies and introduces the set of provisions. It also says which types of entities and applications the document (either a Policy or a Practice Statement) is aimed at 💖

4.1.1. Overview

This subcomponent gives a general intro to the document. It can also describe the entities the Policy or Practice Statement applies to 🦋

4.1.2. Document Name and Identification

This subcomponent lists any applicable names or other identifiers for the document 🏷️

4.1.3. Community and Applicability

This subcomponent identifies the stakeholders and their expected roles and responsibilities 🫶 That includes (but isn't limited to) the entity signing the zone, the entities relying on the signed zone, other entities that depend on the signed zone operationally, and an entity that entrusted the zone signing to someone else 👑

4.1.4. Specification Administration

This subcomponent holds the contact details of the organization in charge of managing the DP/DPS, plus the specification change procedures 📋 These procedures may describe the notification mechanisms used to give advance notice of amendments that are deemed to materially affect the assurance the entity provides, and how and when those amendments get communicated to stakeholders 🔔

If a Policy authority is responsible for deciding whether a DPS is suitable for the Policy, this subcomponent may include the name and contact info of the entity in charge of making that call. If so, it also includes the procedures used to make that determination 🧐

4.2. Publication and Repositories

This component covers the requirements for an entity to publish info about its practices, its public keys, the current status of those keys, and details about the repositories where all that info is kept 📚 It may also cover the responsibility of publishing the DPS, and identifying documents that aren't made public because they're sensitive, like security controls, clearance procedures, or business info 🤫

4.2.1. Repositories

This subcomponent describes the repository mechanisms used to make info available to stakeholders, and it may include:

  • The locations of the repositories and the means by which they may be accessed;
  • An identification of the entity or entities that operate repositories, such as a zone operator or a TLD manager;
  • Access control on published information objects; and
  • Any notification services that stakeholders may subscribe to.

4.2.2. Publication of Public Keys

This subcomponent has info about publishing public keys:

  • Whether the public keys are included in a key hierarchy, published as trust anchors, or both;
  • The data formats and methods available to validate the authenticity of public keys;
  • The frequency and timing of publishing new information (mainly as advance notice for stakeholders relying on the public keys) 🔑

4.3. Operational Requirements

This component describes the operational requirements for running a DNSSEC-signed zone 🛠️

4.3.1. Meaning of Domain Names

This subcomponent describes the overall policy for child zone naming, if there is one 🌸

4.3.2. Identification and Authentication of Child Zone Manager

This subcomponent explains how the child zone manager was initially identified, and how any later change request gets authenticated as coming from the manager or their authorized representative 🪪

4.3.3. Registration of Delegation Signer (DS) Resource Records

This subcomponent describes the process of establishing the chain-of-trust to the child zone by putting delegation signer (DS) record(s) into the zone 🔗

4.3.4. Method to Prove Possession of Private Key

This subcomponent describes whether, and if so under what circumstances, the child zone manager has to prove they hold the private component of any current or future child zone signing key that matches a DS record they want to add to the parent zone 🕵️‍♀️

4.3.5. Removal of DS Resource Records

This subcomponent explains how, when, and under what circumstances DS records may be removed from the zone 🗑️

4.4. Facility, Management, and Operational Controls

This component covers the non-technical security controls (physical, procedural, and personnel) the entity uses to securely perform its DNSSEC-related functions 🏰 Those controls include physical access, key management, disaster recovery, auditing, and archiving 💅

These non-technical controls are super critical for trusting DNSSEC signatures, because lacking security can mess up DNSSEC operations 😭 For example, it could lead to signatures being created with wrong information, or to the signing key getting compromised 💀

Inside each subcomponent, you'll usually need to think separately about each entity type 🧩

4.4.1. Physical Controls

This subcomponent describes the physical controls on the facility that houses the entity's systems. Topics may include:

  • Site location and construction, such as requirements for multiple tiers of physical barriers, construction requirements for high-security areas, etc. It may also describe the use of locked rooms, cages, safes, cabinets, etc.;
  • Physical access, i.e., mechanisms to control access from one area of the facility to another, or extra controls for reaching into higher tiers, such as dual-access control and two-factor authentication;
  • Power and air conditioning;
  • Water exposures;
  • Fire prevention and protection;
  • Media storage, e.g., requiring backup media to be stored in a separate location that is physically secure and protected from fire, smoke, particle, and water damage;
  • Waste disposal; and
  • Off-site backup.

4.4.2. Procedural Controls

This subcomponent describes the requirements for recognizing trusted roles, along with a description of each role's responsibilities 🎭 Examples of trusted roles include system administrators, security officers, crypto officers, and system auditors 👩‍💻

For each task identified, the number of individuals needed to perform the task (m of n rule, if applicable) should be stated for each role 🔢 Identification and authentication requirements for each role may also be defined 🪪

This subcomponent also covers separation of duties, meaning which roles can't be performed by the same individuals 🙅‍♀️

4.4.3. Personnel Controls

This subcomponent addresses the following:

  • Qualifications, experience, and clearances that personnel must have as a condition of filling trusted roles or other important roles. Examples include credentials, job experience, and official government clearances;
  • Background checks and clearance procedures required when hiring personnel for trusted roles or other important roles. Those roles may require checking criminal records, financial records, references, and any additional clearances needed for the position 🔍;
  • Training requirements and training procedures for each role after personnel are hired;
  • Any retraining period and retraining procedures for each role after initial training is complete;
  • Frequency and sequence for job rotation among various roles;
  • Sanctions against personnel for unauthorized actions, such as unauthorized use of authority or unauthorized use of the entity's systems ⚖️;
  • Controls on personnel who are contractors rather than employees of the entity; examples include:
    • Bonding requirements on contract personnel;
    • Contractual requirements, including indemnification for damages caused by the actions of contractor personnel;
    • Auditing and monitoring of contractor personnel; and
    • Other controls on contracting personnel; and
  • Documentation to be supplied to personnel during initial training, retraining, or otherwise 📖

4.4.4. Audit Logging Procedures 📜✨

okay so this subcomponent is all about event logging and audit systems 🕵️‍♀️ the whole point is keeping an audit trail and showing evidence that the process has real integrity. no cap, this is the receipts section 🧾💅 and it covers:

  • Types of events recorded, such as records of key rollover and other key management operations, the personnel assigned to various roles, attempts to access the system, and requests made to the system;
  • Frequency with which audit logs are processed or archived, e.g., weekly following an alarm or anomalous event or whenever the audit log size reaches a particular size;
  • Period for which audit logs are kept;
  • Protection of audit logs:
    • Who can view audit logs, for example, only the audit administrator;
    • Protection against modification of audit logs, for instance, a requirement that no one may modify or delete the audit records or that only an audit administrator may delete an audit file as part of audit file rotation; and
    • Protection against deletion of audit logs.
  • Audit log backup procedures;
  • Whether the audit log collection function is internal or external to the system;
  • Whether the subject who caused an audit event to occur is notified of the audit action; and
  • Vulnerability assessments, for example, where audit data is run through a tool that identifies potential attempts to breach the security of the system.

4.4.5. Compromise and Disaster Recovery 🚨🌪️

this subcomponent is the "when everything goes sideways" section 😭 it describes the notification and recovery plans for compromise or disaster. each of these may need its own handling, so bestie, take them one at a time:

  • Identification or listing of the applicable incident and compromise reporting and handling procedures, which may include the investigation of measures to prevent the event from reoccurring.
  • The recovery procedures used if computing resources, software, and/or data are corrupted or suspected to have been corrupted. These procedures describe how, and under what circumstances, operations of the system are to be suspended; how and when normal operations are resumed; how the stakeholders are to be informed; and how to assess the damage and carry out the root cause analysis.
  • The recovery procedures used if any keys are compromised. These procedures describe how a secure environment is re-established, how the keys are rolled over, how a new trust anchor is provided to the community (if applicable), and how new zone information is published.
  • The entity's capabilities to ensure business continuity following a natural or other disaster. Such capabilities may include the availability of a disaster recovery site at which operations may be recovered. They may also include procedures for securing its facility during the period of time following a natural or other disaster and before a secure environment is re-established, either at the original site or at a disaster recovery site, for example, procedures to protect against theft of sensitive materials from an earthquake-damaged site.

4.4.6. Entity Termination 👋🫶

this one is about ending a contract with an entity, notifying everyone that it's happening, and handing responsibilities over to another entity. the goal is a smooth transition that's transparent to the stakeholders and doesn't mess with the services. iconic exit energy 🌸

4.5. Technical Security Controls 🔐💖

this component is all about the security measures protecting the cryptographic keys and activation data (e.g., PINs, passwords, or manually held key shares) that DNSSEC operations depend on. secure key management is critical 💅 because all secret and private keys and activation data need to be protected and used only by authorized personnel.

also covered here are the other technical security controls used for key generation, authentication, registration, auditing, and archiving. these include life cycle security controls, software development environment security, and operational security controls.

if applicable, other technical security controls on repositories, authoritative name servers, or other participants may also be documented here 🧚

4.5.1. Key Pair Generation and Installation 🗝️

key pair generation and installation need to be considered, which may involve answering these questions:

  1. Who generates the zone's public/private key pairs? How is the key generation performed? Is the key generation performed by hardware or software?
  2. How is the private key installed in all parts of the key management system?
  3. How are the zone's public keys provided securely to the parent zone and potential relying parties?
  4. Who generates the public key parameters. Is the quality of the parameters checked during key generation?
  5. For what purposes may the keys be used, and/or for what purposes should usage of the key be restricted?

4.5.2. Private Key Protection and Cryptographic Module Engineering Controls 🛡️🔑

requirements for private key protection and cryptographic modules need to be considered for key generation and creation of signatures. the following questions may need to be answered, and honestly these are a whole vibe 😭

  1. What standards, if any, are required for the cryptographic module used to generate the keys? A cryptographic module can be composed of hardware, software, firmware, or any combination of them. For example, are the zone's signatures required to be generated using modules compliant with the US FIPS 140-2 [FIPS-140-2] standard? If so, what is the required FIPS 140-2 level of the module? Are there any other engineering or other controls relating to a cryptographic module, such as the identification of the cryptographic module boundary, input/output, roles and services, finite state machine, physical security, software security, operating system security, algorithm compliance, electromagnetic compatibility, and self tests?
  2. Is the private key under m of n multi-person control? If yes, provide m and n (two-person control is a special case of m of n, where m = 2 and n >= 2).
  3. Is the private key escrowed? If so, who is the escrow agent, in what form is the key escrowed (e.g., plaintext, encrypted, split key), and what are the security controls on the escrow system?
  4. Is the private key backed up? If so, who is the backup agent, in what form is the key backed up (e.g., plaintext, encrypted, split key), and what are the security controls on the backup system?
  5. Is the private key archived? If so, who is the archival agent, in what form is the key archived (e.g. plaintext, encrypted, split key), and what are the security controls on the archival system?
  6. Under what circumstances, if any, can a private key be transferred into or from a cryptographic module? Who is permitted to perform such a transfer operation? In what form is the private key during the transfer (e.g., plaintext, encrypted, or split key)?
  7. How is the private key stored in the module (e.g., plaintext, encrypted, or split key)?
  8. Who can activate (use) the private key? What actions must be performed to activate the private key (e.g., login, power on, supply PIN, insert token/key, automatic, etc.)? Once the key is activated, is the key active for an indefinite period, active for one time, or active for a defined time period?
  9. Who can deactivate the private key and how? Examples of methods of deactivating private keys include logging out, turning the power off, removing the token/key, automatic deactivation, and time expiration.
  10. Who can destroy the private key and how? Examples of methods of destroying private keys include token surrender, token destruction, and zeroizing the key.

4.5.3. Other Aspects of Key Pair Management 🔄

other aspects of key management need to be considered for the zone operator and other participants. for each of these types of entities, these questions may need to be answered:

  1. What are the life cycle states for the management of any signing keys?
  2. What is the operational period of these keys? What are the usage periods or active lifetimes for the pairs?

4.5.4. Activation Data 🔓

activation data means data values other than whole private keys that are required to operate private keys or cryptographic modules containing private keys, such as a PIN, passphrase, or portions of a private key used in a key-splitting scheme. protecting it stops unauthorized use of the private key, and it potentially needs to be considered for the zone operator and other participants. that consideration may need to cover the entire life cycle of the activation data, from generation through archival and destruction. for each of the entity types, all of the questions listed in Sections 4.5.1 through 4.5.3 potentially need to be answered with respect to activation data rather than with respect to keys. 🫶

4.5.5. Computer Security Controls 💻🛡️

this subcomponent describes computer security controls such as:

  1. use of the trusted computing base concept or equivalent;
  2. discretionary access control, labels, mandatory access controls;
  3. object reuse;
  4. auditing;
  5. identification and authentication;
  6. trusted path; and
  7. security testing.

this subcomponent may also address requirements for product assurance, product evaluation analysis, testing, profiling, product certification, and/or product accreditation. ✨

4.5.6. Network Security Controls 🌐🔥

this subcomponent covers network security related controls, including firewalls, routers, and remote access. the network perimeter, but make it slay 🏰

4.5.7. Timestamping ⏰

this subcomponent addresses requirements or practices relating to the use of timestamps on various data. it may also discuss whether or not the timestamping application must use a trusted time source. ⏱️💜

4.5.8. Life Cycle Technical Controls 🔁🌈

this subcomponent addresses system development controls and security management controls.

system development controls include development environment security, development personnel security, configuration management security during product maintenance, software engineering practices, software development methodology, modularity, layering, use of fail-safe design and implementation techniques (e.g., defensive programming), and development facility security. the main character energy of building software safely 👑

security management controls include execution of tools and procedures to ensure that the operational systems and networks adhere to configured security. these tools and procedures include checking the integrity of the security software, firmware, and hardware to ensure their correct operation. iykyk, it's the checklist that keeps everything honest 🧚‍♀️

4.6. Zone Signing 🔐

Okay bestie, this part is all about zone signing 💅. It covers everything: the crypto around the signing keys, the signing scheme, how keys roll over, and the actual signing of the zone. Child zones and other relying parties can use this section to figure out what the signed zone is supposed to look like and how they should behave around it. 🫶 If there's any compliance stuff for zone signing (cryptographic or operational), this is where it gets stated ✨.

4.6.1. Key Lengths, Key Types, and Algorithms 🔑

This subcomponent covers the key generation algorithm, the key types used to sign the key set and the zone data, and the key lengths used to make the keys. It should also explain how these key lengths, key types, and algorithms can be changed 🦋.

4.6.2. Authenticated Denial of Existence 🙈

Authenticated denial of existence is about using NSEC [RFC4034], NSEC3 [RFC5155], or any other mechanism defined later that authenticates the denial of existence of resource records. This subcomponent describes which mechanisms are used, any parameters that go with them, and how those mechanisms and parameters can be changed 🌸.

4.6.3. Signature Format 🖋️

This subcomponent describes the signing method and the algorithms used for zone signing. Very important, very precise 💜.

4.6.4. Key Rollover 🔄

This subcomponent explains the key rollover scheme for each key type. Every key type gets its own rollover plan, no shortcuts 👑.

4.6.5. Signature Lifetime and Re-Signing Frequency ⏳

This subcomponent describes the life cycle of the Resource Record Signature (RRSIG) record. It's giving "every signature has a life story" 🎀.

4.6.6. Verification of Resource Records ✅

This subsection covers the controls around verifying resource records, so the data to be signed is validated and authenticated first. If a split key signing scheme is being used, this may include a separate key set verification process 🧚.

4.6.7. Resource Records Time-to-Live ⏱️

This subcomponent specifies the time-to-live (TTL) for the resource records of all DNSSEC-relevant types, plus any global parameters that affect how resolver caching works 🍓.

4.7. Compliance Audit 📝

To prove compliance with a Policy or with the statements in the Practice Statement, a compliance audit can be conducted. This component describes how the audit is carried out at the zone operator and, possibly, at other entities involved 🕵️‍♀️.

4.7.1. Frequency of Entity Compliance Audit 📅

This subcomponent describes how often the compliance audit happens 💅.

4.7.2. Identity/Qualifications of Auditor 🎓

This subcomponent covers what qualifications the auditor needs to have. For example, the auditor might need to belong to a specific association or hold certain certifications 🦋.

4.7.3. Auditor's Relationship to Audited Party 🤝

This subcomponent clarifies the relationship between the auditor and the entity being audited. It matters a lot if there are any requirements or guidelines for picking the auditor 👀.

4.7.4. Topics Covered by Audit 📚

What the audit covers depends on its scope. Since the DNSSEC Policy and Practice Statement is the document being audited against, it's ideal to set the audit's scope to match the scope of the DP/DPS 🎯. The scope can be narrowed or expanded when needed, like if there aren't enough resources for a full audit, or if part of the system is still under development and not ready to be audited 🌈.

4.7.5. Actions Taken as a Result of Deficiency 🛠️

This subcomponent specifies the action taken to fix any discrepancy that has a security impact. That could be the remediation process for audit findings, or any other action to correct a discrepancy with the DNSSEC Policy or Practice Statement 🚨.

4.7.6. Communication of Results 📣

This subcomponent specifies how the audit results get communicated to the stakeholders 💌.

Bringing DNSSEC into a zone may have legal implications. So it may be appropriate to declare the legal status of the binding in the DNSSEC digital signatures, and to spell out any limitations of liability claimed by the registry manager 📜.

In most cases, the DPS isn't a contract or part of one. Instead, it's set up so its terms and conditions get applied to the parties through separate documents, like registrar or registrant agreements 🤓. In other cases, its contents may form part of a legal contract between parties (either directly or through other agreements). If that's the case, legal expertise should be consulted when drafting any sections that may have contractual implications 💼.

At a minimum, the Legal Matters section should say which jurisdiction the registry operates under, and point to any associated agreements that are in force 🗺️. It may also be appropriate to note any identified implications for the protection of personally identifiable private information 🔒.

5. Outline of a Set of Provisions 🗂️

This section contains a recommended outline for a set of provisions. It's meant to work as a checklist or a standard template for DP or DPS writers ✅. A common outline makes these things easier:

  • (a) Comparing a DPS with a DP, to make sure the DPS faithfully implements the policy.
  • (b) Comparing two DPSs.

Section 4 of this document is structured so that it gives guidance for each corresponding component and subcomponent of the outline 💖.

   1.  INTRODUCTION
     1.1.  Overview
     1.2.  Document name and identification
     1.3.  Community and applicability
     1.4.  Specification administration
       1.4.1.  Specification administration organization
       1.4.2.  Contact information
       1.4.3.  Specification change procedures
   2.  PUBLICATION AND REPOSITORIES
     2.1.  Repositories
     2.2.  Publication of public keys
   3.  OPERATIONAL REQUIREMENTS
     3.1.  Meaning of domain names
     3.2.  Identification and authentication of child zone manager
     3.3.  Registration of delegation signer (DS) resource records
     3.4.  Method to prove possession of private key
     3.5.  Removal of DS resource records
       3.5.1.  Who can request removal
       3.5.2.  Procedure for removal request
       3.5.3.  Emergency removal request
   4.  FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS
     4.1.  Physical controls
       4.1.1.  Site location and construction
       4.1.2.  Physical access
       4.1.3.  Power and air conditioning
       4.1.4.  Water exposures
       4.1.5.  Fire prevention and protection
       4.1.6.  Media storage
       4.1.7.  Waste disposal
       4.1.8.  Off-site backup
     4.2.  Procedural controls
       4.2.1.  Trusted roles
       4.2.2.  Number of persons required per task
       4.2.3.  Identification and authentication for each role
       4.2.4.  Tasks requiring separation of duties
     4.3.  Personnel controls
       4.3.1.  Qualifications, experience, and clearance
               requirements
       4.3.2.  Background check procedures
       4.3.3.  Training requirements
       4.3.4.  Job rotation frequency and sequence
       4.3.5.  Sanctions for unauthorized actions
       4.3.6.  Contracting personnel requirements
       4.3.7.  Documentation supplied to personnel
     4.4.  Audit logging procedures
       4.4.1.  Types of events recorded
       4.4.2.  Frequency of processing log
       4.4.3.  Retention period for audit log information
       4.4.4.  Protection of audit log
       4.4.5.  Audit log backup procedures
       4.4.6.  Audit collection system
       4.4.7.  Vulnerability assessments
     4.5.  Compromise and disaster recovery
       4.5.1.  Incident and compromise handling procedures
       4.5.2.  Corrupted computing resources, software, and/or
               data
       4.5.3.  Entity private key compromise procedures
       4.5.4.  Business continuity and IT disaster recovery
               capabilities
     4.6.  Entity termination

   5.  TECHNICAL SECURITY CONTROLS
     5.1.  Key pair generation and installation
       5.1.1.  Key pair generation
       5.1.2.  Public key delivery
       5.1.3.  Public key parameters generation and quality
               checking
       5.1.4.  Key usage purposes
     5.2.  Private key protection and cryptographic module
           engineering controls
       5.2.1.  Cryptographic module standards and controls
       5.2.2.  Private key (m-of-n) multi-person control
       5.2.3.  Private key escrow
       5.2.4.  Private key backup
       5.2.5.  Private key storage on cryptographic module
       5.2.6.  Private key archival
       5.2.7.  Private key transfer into or from a cryptographic
               module
       5.2.8.  Method of activating private key
       5.2.9.  Method of deactivating private key
       5.2.10. Method of destroying private key
     5.3.  Other aspects of key pair management
     5.4.  Activation data
       5.4.1.  Activation data generation and installation
       5.4.2.  Activation data protection
       5.4.3.  Other aspects of activation data
     5.5.  Computer security controls
     5.6.  Network security controls
     5.7.  Timestamping
     5.8.  Life cycle technical controls
   6.  ZONE SIGNING
     6.1.  Key lengths, key types, and algorithms
     6.2.  Authenticated denial of existence
     6.3.  Signature format
     6.4.  Key rollover
     6.5.  Signature lifetime and re-signing frequency
     6.6.  Verification of resource records
     6.7.  Resource records time-to-live
   7.  COMPLIANCE AUDIT
     7.1.  Frequency of entity compliance audit
     7.2.  Identity/qualifications of auditor
     7.3.  Auditor's relationship to audited party
     7.4.  Topics covered by audit
     7.5.  Actions taken as a result of deficiency
     7.6.  Communication of results
   8.  LEGAL MATTERS

6. Security Considerations 🚨

The sensitivity of the information protected by DNSSEC varies a lot at different tiers of the DNS tree. On top of that, there are no restrictions on what types of information (i.e., DNS records) can be protected using DNSSEC 😭. So each relying party has to evaluate its own environment, and the chain of trust that starts from a trust anchor, along with the associated threats and vulnerabilities. That's how it works out how much risk it's willing to accept when relying on DNSSEC-protected objects 💀.

7. Acknowledgements 🙏

This document is inspired by RFC 3647 and its predecessor (RFC 2527), and the authors acknowledge the work that went into developing those documents 🌷.

The authors would also like to acknowledge the contributions made by Richard Lamb, Jakob Schlyter, and Stephen Morris 🫶✨.

8. References 📚

8.1. Normative References

[RFC4033]     Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

[RFC4034]     Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security
              Extensions", RFC 4034, March 2005.

[RFC4035]     Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

8.2. Informative References 📚

okay so these are the "just for context" refs, bestie 🧚 they're not required to implement the thing, but they're giving background. 💅

[FIPS-140-2]  NIST, "Security Requirements for Cryptographic
              Modules", June 2005, <http://csrc.nist.gov/
              publications/fips/fips140-2/fips1402.pdf>.

[RFC3647]     Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
              Wu, "Internet X.509 Public Key Infrastructure
              Certificate Policy and Certification Practices
              Framework", RFC 3647, November 2003.

[RFC5155]     Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
              Security (DNSSEC) Hashed Authenticated Denial of
              Existence", RFC 5155, March 2008.

Authors' Addresses ✨

and here are the lovely humans who wrote this, bestie 🎀 you can reach out to them over email if you ever need to 💌

Fredrik Ljunggren
Kirei AB
P.O. Box 53204
Goteborg  SE-400 16
Sweden

EMail: fredrik@kirei.se


Anne-Marie Eklund Lowinder
.SE (The Internet Infrastructure Foundation)
P.O. Box 7399
Stockholm  SE-103 91
Sweden

EMail: amel@iis.se


Tomofumi Okubo
Internet Corporation For Assigned Names and Numbers
4676 Admiralty Way, Suite 330
Marina del Ray, CA  90292
USA

EMail: tomofumi.okubo@icann.org
📦 where this page comes from