RZ KSK PMA April 7, 2020 DNSSEC Practice Statement for the Root Zone KSK Operator Abstract This document is the DNSSEC Practice Statement (DPS) for the Root Zone Key Signing Key (KSK) Operator. It states the practices and provisions that are used to provide Root Zone Key Signing and Key Distribution services. These include, but are not limited to: issuing, managing, changing and distributing DNS keys. Copyright Notice Copyright 2009-2020 Internet Corporation for Assigned Names and Numbers. Copyright 2009 VeriSign, Inc. This work is based on the Certification Practice Statement, Copyright 1996-2004 by Verisign, Inc. Used by Permission. All Rights Reserved. Trademark Notices ICANN is a registered trademark of the Internet Corporation for Assigned Names and Numbers. VERISIGN is a registered trademark of Verisign, Inc. Table of Contents 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Document name and identification . . . . . . . . . . . . 5 1.3. Community and Applicability . . . . . . . . . . . . . . . 5 1.3.1. Root Zone Manager . . . . . . . . . . . . . . . . . . 6 1.3.2. Root Zone Maintainer . . . . . . . . . . . . . . . . 6 1.3.3. Root Server Operators . . . . . . . . . . . . . . . . 6 1.3.4. Root Zone Key Signing Key Operator . . . . . . . . . 6 1.3.5. Root Zone Zone Signing Key Operator . . . . . . . . . 7 1.3.6. Child zone manager . . . . . . . . . . . . . . . . . 7 1.3.7. Relying Party . . . . . . . . . . . . . . . . . . . . 8 1.3.8. Applicability . . . . . . . . . . . . . . . . . . . . 8 1.4. Specification Administration . . . . . . . . . . . . . . 8 1.4.1. Specification administration organization . . . . . . 9 1.4.2. Contact Information . . . . . . . . . . . . . . . . . 9 1.4.3. Specification change procedures . . . . . . . . . . . 9 2. PUBLICATION AND REPOSITORIES . . . . . . . . . . . . . . . . 10 2.1. Repositories . . . . . . . . . . . . . . . . . . . . . . 10 [Page 1] Root Zone KSK Operator DPS April 2020 2.2. Publication of key signing keys . . . . . . . . . . . . . 10 2.3. Access controls on repositories . . . . . . . . . . . . . 10 3. OPERATIONAL REQUIREMENTS . . . . . . . . . . . . . . . . . . 10 3.1. Meaning of domain names . . . . . . . . . . . . . . . . . 10 3.2. Activation of DNSSEC for child zone . . . . . . . . . . . 10 3.3. Identification and authentication of child zone manager . 11 3.4. Registration of delegation signer (DS) resource records . 11 3.5. Method to prove possession of private key . . . . . . . . 11 3.6. Removal of DS resource records . . . . . . . . . . . . . 11 3.6.1. Who can request removal . . . . . . . . . . . . . . . 11 3.6.2. Procedure for removal request . . . . . . . . . . . . 11 3.6.3. Emergency removal request . . . . . . . . . . . . . . 12 4. FACILITY, MANAGEMENT AND OPERATIONAL CONTROLS . . . . . . . . 12 4.1. Physical Controls . . . . . . . . . . . . . . . . . . . . 12 4.1.1. Site location and construction . . . . . . . . . . . 12 4.1.2. Physical access . . . . . . . . . . . . . . . . . . . 12 4.1.3. Power and air conditioning . . . . . . . . . . . . . 13 4.1.4. Water exposures . . . . . . . . . . . . . . . . . . . 13 4.1.5. Fire prevention and protection . . . . . . . . . . . 13 4.1.6. Media storage . . . . . . . . . . . . . . . . . . . . 13 4.1.7. Waste disposal . . . . . . . . . . . . . . . . . . . 13 4.1.8. Off-site backup . . . . . . . . . . . . . . . . . . . 14 4.2. Procedural Controls . . . . . . . . . . . . . . . . . . . 14 4.2.1. Trusted roles . . . . . . . . . . . . . . . . . . . . 14 4.2.2. Number of persons required per task . . . . . . . . . 15 4.2.3. Identification and authentication for each role . . . 16 4.2.4. Tasks requiring separation of duties . . . . . . . . 16 4.3. Personnel Controls . . . . . . . . . . . . . . . . . . . 16 4.3.1. Qualifications, experience, and clearance requirements . . . . . . . . . . . . . . . . . . . . 16 4.3.2. Background check procedures . . . . . . . . . . . . . 17 4.3.3. Training requirements . . . . . . . . . . . . . . . . 18 4.3.4. Retraining frequency and requirements . . . . . . . . 18 4.3.5. Job rotation frequency and sequence . . . . . . . . . 18 4.3.6. Sanctions for unauthorized actions . . . . . . . . . 19 4.3.7. Contracting personnel requirements . . . . . . . . . 19 4.3.8. Documentation supplied to personnel . . . . . . . . . 19 4.4. Audit Logging Procedures . . . . . . . . . . . . . . . . 19 4.4.1. Types of events recorded . . . . . . . . . . . . . . 19 4.4.2. Frequency of processing log . . . . . . . . . . . . . 20 4.4.3. Retention period for audit log information . . . . . 21 4.4.4. Protection of audit log . . . . . . . . . . . . . . . 21 4.4.5. Audit log backup procedures . . . . . . . . . . . . . 21 4.4.6. Audit collection system . . . . . . . . . . . . . . . 21 4.4.7. Notification to event-causing subject . . . . . . . . 21 4.4.8. Vulnerability assessments . . . . . . . . . . . . . . 22 4.5. Compromise and Disaster Recovery . . . . . . . . . . . . 22 4.5.1. Incident and compromise handling procedures . . . . . 22 [Page 2] Root Zone KSK Operator DPS April 2020 4.5.2. Corrupted computing resources, software, and/or data 22 4.5.3. Entity private key compromise procedures . . . . . . 22 4.5.4. Business Continuity and IT Disaster Recovery Capabilities . . . . . . . . . . . . . . . . . . . . 24 4.6. Entity termination . . . . . . . . . . . . . . . . . . . 25 5. TECHNICAL SECURITY CONTROLS . . . . . . . . . . . . . . . . . 25 5.1. Key Pair Generation and Installation . . . . . . . . . . 25 5.1.1. Key pair generation . . . . . . . . . . . . . . . . . 26 5.1.2. Public key delivery . . . . . . . . . . . . . . . . . 26 5.1.3. Public key parameters generation and quality checking . . . . . . . . . . . . . . . . . . . . . . 26 5.1.4. Key usage purposes . . . . . . . . . . . . . . . . . 27 5.2. Private key protection and Cryptographic Module Engineering Controls . . . . . . . . . . . . . . . . . . 27 5.2.1. Cryptographic module standards and controls . . . . . 27 5.2.2. Private key (m-of-n) multi-person control . . . . . . 27 5.2.3. Private key escrow . . . . . . . . . . . . . . . . . 28 5.2.4. Private key backup . . . . . . . . . . . . . . . . . 28 5.2.5. Private key storage on cryptographic module . . . . . 28 5.2.6. Private key archival . . . . . . . . . . . . . . . . 28 5.2.7. Private key transfer into or from a cryptographic module . . . . . . . . . . . . . . . . . . . . . . . 28 5.2.8. Method of activating private key . . . . . . . . . . 28 5.2.9. Method of deactivating private key . . . . . . . . . 29 5.2.10. Method of destroying private key . . . . . . . . . . 29 5.3. Other Aspects of Key Pair Management . . . . . . . . . . 29 5.3.1. Public key archival . . . . . . . . . . . . . . . . . 29 5.3.2. Key usage periods . . . . . . . . . . . . . . . . . . 29 5.4. Activation data . . . . . . . . . . . . . . . . . . . . . 29 5.4.1. Activation data generation and installation . . . . . 29 5.4.2. Activation data protection . . . . . . . . . . . . . 29 5.4.3. Other aspects of activation data . . . . . . . . . . 30 5.5. Computer Security Controls . . . . . . . . . . . . . . . 30 5.6. Network Security Controls . . . . . . . . . . . . . . . . 30 5.7. Timestamping . . . . . . . . . . . . . . . . . . . . . . 30 5.8. Life Cycle Technical Controls . . . . . . . . . . . . . . 31 5.8.1. System development controls . . . . . . . . . . . . . 31 5.8.2. Security management controls . . . . . . . . . . . . 32 5.8.3. Life cycle security controls . . . . . . . . . . . . 32 6. ZONE SIGNING . . . . . . . . . . . . . . . . . . . . . . . . 32 6.1. Key lengths and algorithms . . . . . . . . . . . . . . . 32 6.2. Authenticated denial of existence . . . . . . . . . . . . 33 6.3. Signature format . . . . . . . . . . . . . . . . . . . . 33 6.4. Zone signing key roll-over . . . . . . . . . . . . . . . 33 6.5. Key signing key roll-over . . . . . . . . . . . . . . . . 33 6.6. Signature life-time and re-signing frequency . . . . . . 33 6.7. Verification of zone signing key set . . . . . . . . . . 36 6.8. Verification of resource records . . . . . . . . . . . . 36 [Page 3] Root Zone KSK Operator DPS April 2020 6.9. Resource records time-to-live . . . . . . . . . . . . . . 36 7. COMPLIANCE AUDIT . . . . . . . . . . . . . . . . . . . . . . 36 7.1. Frequency of entity compliance audit . . . . . . . . . . 36 7.2. Identity/qualifications of auditor . . . . . . . . . . . 37 7.3. Auditor's relationship to audited party . . . . . . . . . 37 7.4. Topics covered by audit . . . . . . . . . . . . . . . . . 37 7.5. Actions taken as a result of deficiency . . . . . . . . . 37 7.6. Communication of results . . . . . . . . . . . . . . . . 38 8. LEGAL MATTERS . . . . . . . . . . . . . . . . . . . . . . . . 38 8.1. Fees . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8.2. Financial responsibility . . . . . . . . . . . . . . . . 38 8.3. Confidentiality of business information . . . . . . . . . 38 8.3.1. Scope of confidential information . . . . . . . . . . 38 8.3.2. Information not within the scope of confidential information . . . . . . . . . . . . . . . . . . . . . 39 8.3.3. Responsibility to protect confidential information . 39 8.4. Privacy of personal information . . . . . . . . . . . . . 39 8.4.1. Information treated as private . . . . . . . . . . . 39 8.4.2. Types of information not considered private . . . . . 39 8.4.3. Responsibility to protect private information . . . . 39 8.4.4. Disclosure Pursuant to Judicial or Administrative Process . . . . . . . . . . . . . . . . . . . . . . . 39 8.5. Limitations of liability . . . . . . . . . . . . . . . . 39 8.6. Term and termination . . . . . . . . . . . . . . . . . . 40 8.6.1. Term . . . . . . . . . . . . . . . . . . . . . . . . 40 8.6.2. Termination . . . . . . . . . . . . . . . . . . . . . 40 8.6.3. Dispute resolution provisions . . . . . . . . . . . . 40 8.6.4. Governing law . . . . . . . . . . . . . . . . . . . . 40 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 9.1. Normative References . . . . . . . . . . . . . . . . . . 40 9.2. Informative References . . . . . . . . . . . . . . . . . 40 Appendix A. Table of acronyms and definitions . . . . . . . . . 41 A.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 41 A.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 42 Appendix B. History of changes . . . . . . . . . . . . . . . . . 45 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 47 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 47 1. INTRODUCTION This document is the DNSSEC Practice Statement (DPS) for Public Technical Identifiers (PTI) performing the Root Zone Key Signing Key Operator role described within. It states the practices and provisions that PTI employs in providing Root Zone Key Signing and Key Distribution services. [Page 4] Root Zone KSK Operator DPS April 2020 1.1. Overview The Domain Name System Security Extensions (DNSSEC) is a set of IETF specifications for adding origin authentication and data integrity to the Domain Name System. DNSSEC provides a way for software to validate that Domain Name System (DNS) data has not been modified during Internet transit. This is done by incorporating public key cryptography into the DNS hierarchy to form a chain of trust originating at the root zone. The DNS was not originally designed with strong security mechanisms to provide integrity and authenticity of DNS data. Over the years, a number of vulnerabilities have been discovered that threaten the reliability and trustworthiness of the system. DNSSEC addresses these vulnerabilities by adding data origin authentication, data integrity verification and authenticated denial of existence capabilities to the DNS. This DPS is specifically applicable to the Root Zone Key Signing Key Operator. PTI performs this role by virtue of the IANA Naming Functions agreement with the Internet Corporation for Assigned Names and Numbers (ICANN). More generally, this document provides the governing practices and provisions related to the management, security and technical specifications of DNSSEC operation at the Root. This document will be under the control and management of PTI with guidance and direction from ICANN. Information in this document and subsequent documents will be made public as required. The DPS is only one of a set of documents relevant to PTI's management of the Root Zone's Key Signing Key. Other documents supplement the DPS by providing more detailed requirements. In some instances, the DPS refers to these ancillary documents for specific, detailed practices implementing certain policies where including the specifics are not relevant to the purpose of the DPS. 1.2. Document name and identification Document title: DNSSEC Practice Statement for the Root Zone KSK Operator Version: 5th Edition (2020-04-07) 1.3. Community and Applicability [Page 5] Root Zone KSK Operator DPS April 2020 1.3.1. Root Zone Manager Public Technical Identifiers (PTI) performs the management of the DNS Root Zone. This role includes accepting change requests to the contents of the Root Zone from the Top Level Domain (TLD) Operators and validating those requests. After validation occurs, implementation is performed by the Root Zone Maintainer. PTI is an affiliate of the Internet Corporation for Assigned Names and Numbers (ICANN), and performs these functions under an "IANA Naming Functions" contract from ICANN using the facilities, property and staff of ICANN under a service agreement. 1.3.2. Root Zone Maintainer Verisign is acting as the Root Zone Maintainer. They have historically performed this role under an agreement with the U.S. Government and have entered into an agreement to perform this function under contract from ICANN. The Root Zone Maintainer performs the function of receiving validated change requests to the Root Zone from the Root Zone Manager, implementing the changes, generating a new Root Zone File and distributing it to the Root Server Operators. 1.3.3. Root Server Operators The Root Server Operators consist of 12 different professional engineering entities responsible for providing the root zone to the public via the 13 Root Zone Authoritative Name Servers. The Root Server Operators are not involved in the making of any policies or modification of data. 1.3.4. Root Zone Key Signing Key Operator PTI performs the Root Zone Key Signing Key (RZ KSK) Operator function of generating the RZ KSK and signing the Root Keyset, including the Root Zone Zone Signing Key (RZ ZSK), using the KSK. The RZ KSK Operator is also responsible for securely generating and storing the private keys and distributing the public portion of the KSK (the Trust Anchor) to the relying parties. The RZ KSK Operator is responsible for: (1) Generating and protecting the private component of the RZ KSK. [Page 6] Root Zone KSK Operator DPS April 2020 (2) Securely importing public key components from the RZ ZSK Operator. (3) Authenticating and validating the public RZ ZSK keyset. (4) Securely signing the RZ ZSK keyset. (5) Securely transmitting the signed RZ ZSK key set to the RZ ZSK Operator. (6) Securely exporting the RZ KSK public key components. (7) Issuing an emergency key roll-over within a reasonable time if any private key component associated with the zone is lost or suspected to be compromised. 1.3.5. Root Zone Zone Signing Key Operator The RZ ZSK Operator is Verisign performing the function of generating the RZ ZSK and signing the Root Zone File using the ZSK. The RZ ZSK Operator is also responsible for securely generating and storing the private keys and distributing the public portion of the ZSK to the RZ KSK Operator for signing. The RZ ZSK Operator is responsible for: (1) Generating and protecting the private component of the RZ ZSK. (2) Securely exporting and transmitting the public RZ ZSK component to the RZ KSK Operator. (3) Securely importing the signed RZ ZSK keyset from the RZ KSK Operator. (4) Signing the Root Zone's resource records (optionally omitting the DNSKEY resource record). (5) Issue emergency key roll-over within a reasonable amount of time if any private key component associated with the zone is lost or suspected to be compromised. 1.3.6. Child zone manager The child zone (TLD) manager is a trustee for the delegated domain, and as such responsible for providing registry services and operating [Page 7] Root Zone KSK Operator DPS April 2020 subordinate DNS servers. If a child zone is signed using DNSSEC, the child zone manager is also responsible for: (1) Generating the keys associated with its zone using a trustworthy method. (2) Registering and maintaining the shorthand representations of its Key Signing Key (Delegation Signer Resource Record) in the parent zone to establish the chain of trust. (3) Taking reasonable precautions to prevent any loss, disclosure or unauthorized use of the keys associated with its zone. (4) Issuing emergency key roll-over within reasonable time if any private key associated with its zone is lost or suspected to be compromised. 1.3.7. Relying Party A Relying Party is the entity that relies on DNSSEC, such as security-aware validating resolvers and other applications that perform validation of DNSSEC signatures. The relying party must properly authenticate, configure and update the Trust Anchors as appropriate. The automated method described in RFC 5011 [RFC5011] may be used. Relying parties must be informed of any critical changes in the Root Zone operation as notified by the RZ KSK Operator in accordance with section 2.1. 1.3.8. Applicability This DPS is only applicable to the Root Zone, and more specifically the RZ KSK Operator. Each link in the chain of trust may have entirely different requirements that can affect the end entity, and is not governed by this DPS. Entities must evaluate their own environments and its associated threats and vulnerabilities to determine the level of risk they are willing to accept. 1.4. Specification Administration This DPS will be periodically reviewed and updated, as appropriate by the RZ KSK Operator Policy Management Authority (PMA). The PMA is comprised of representatives of PTI and ICANN and is responsible for [Page 8] Root Zone KSK Operator DPS April 2020 the management of the DPS. The PMA should be considered as the point of contact for all matters related to the DPS. 1.4.1. Specification administration organization Public Technical Identifiers 12025 Waterfront Drive, Suite 300 Los Angeles CA 90094 USA 1.4.2. Contact Information RZ KSK Operator Policy Management Authority Public Technical Identifiers 12025 Waterfront Drive, Suite 300 Los Angeles CA 90094 USA +1 (424) 254-5300 (voice) +1 (424) 254-5033 (fax) root-ksk-pma@iana.org 1.4.3. Specification change procedures Amendments to this DPS are made by the RZ KSK Operator Policy Management Authority (PMA). Amendments will either be in the form of a document containing an amended form of the DPS or an update. Amended versions or updates will be linked to the Practices Updates and Notices section of the RZ KSK Operator's Repository (See section 2.1). Updates supersede any designated or conflicting provisions of the referenced version of the DPS. The PMA reserves the right to amend the DPS without notification for amendments that are not material, including without limitation corrections of typographical errors, changes to URLs, and changes to contact information. The PMA's decision to designate amendments as material or non-material is within the PMA's sole discretion. Amendments to the DPS, and proposal to amend the DPS, will appear in the RZ KSK Operator's Repository, which is located at . The PMA solicits proposed amendments to the DPS from the community. If the PMA considers such an amendment desirable, the PMA will provide public notice of such amendment in accordance with this section. Should the PMA determine that material amendments to the DPS are necessary immediately to stop or prevent a breach of the security of any portion of it, the PMA is entitled to make such amendments. Updates to the DPS are published in the RZ KSK Operator's Repository, and such amendments are effective immediately upon publication. [Page 9] Root Zone KSK Operator DPS April 2020 2. PUBLICATION AND REPOSITORIES 2.1. Repositories The RZ KSK Operator publishes the DPS in the repository section of the IANA web site at . Public access to this repository will include the option of using an HTTPS- authenticated channel. Announcements relevant to DNSSEC in the Root Zone will also be posted on an announcement-only mailing list. Subscription and related information for the mailing list can be found at . 2.2. Publication of key signing keys The public portion of the Root Zone Key Signing Key will be posted in the RZ KSK Operator's repository as a Trust Anchor along with mechanisms to validate its integrity. Refer to "DNSSEC Trust Anchor Publication for the Root Zone" [RFC7958] for details. 2.3. Access controls on repositories Read-only access to the information posted in the repository is unrestricted. The RZ KSK Operator has implemented logical and physical security measures to prevent unauthorized persons from adding, deleting, or modifying repository entries. 3. OPERATIONAL REQUIREMENTS 3.1. Meaning of domain names DNSSEC provides mechanisms for ensuring that the origin of the DNS data is consistent with the information in the registry. It does not provide any way of determining the legal entity behind the domain name, or the relevance of the domain name itself. Refer to the Root Zone Manager function for details on top-level domain name assignments. 3.2. Activation of DNSSEC for child zone The DNSSEC chain of trust from the RZ to a child zone is activated by the publishing of a signed Delegation Signer (DS) record for that child zone in the root zone. The DS record is a cryptographic shorthand representation, or hash, of the child zone generated and [Page 10] Root Zone KSK Operator DPS April 2020 controlled Key Signing Key. It will establish a chain of trust from the Root Zone to the Child Zone. The child zone manager must submit the DS record to request activation of DNSSEC. In this DPS, the child zone is equivalent to TLD. 3.3. Identification and authentication of child zone manager The identity and authority of the Child Zone Manager will be verified using the appropriate method for that specific child zone. 3.4. Registration of delegation signer (DS) resource records The Delegation Signer (DS) resource record provided by the Child Zone Manager is vetted and processed by the Root Zone Manager and incorporated into a change request. The DS resource record must be valid and submitted in the DS RR Presentation Format as described in RFC 4034 [RFC4034]. As part of the vetting process the DS record is checked against the child zones DNSKEY keyset and signatures. After processing by the Root Zone Manager, the DS resource record is incorporated into the Root Zone and signed by the Root Zone Maintainer. 3.5. Method to prove possession of private key The Root Zone Manager will take effort to ensure the availability and integrity of the child zone by validating the DS resource record to the currently published DNSKEY RRSIGs. If a DS resource record does not validate, there will be an out-of-band process in order to confirm the authenticity and intention of publishing the DS resource record. 3.6. Removal of DS resource records 3.6.1. Who can request removal The removal of DS resource records (stale or active) can only be requested by the Child Zone Manager. 3.6.2. Procedure for removal request Delegation Signer (DS) removal requests is vetted and processed by the Root Zone Manager like any other changes to the Root Zone file. Upon reception of the request and authentication of the requester, the Root Zone Manager will conduct checks to confirm the removal of [Page 11] Root Zone KSK Operator DPS April 2020 the relevant key from the child's zones DNSKEY RRset as part of the vetting process. 3.6.3. Emergency removal request If the Child Zone Manager is unable to produce a valid DNSSEC signed zone, the manager of that zone may request an emergency removal of the DS resource record following the Root Zone Manager's emergency change process. The emergency change process will be completed within 48 hours from the reception of a valid Emergency removal request. 4. FACILITY, MANAGEMENT AND OPERATIONAL CONTROLS 4.1. Physical Controls The RZ KSK Operator has implemented physical security controls, which support the security requirements of this DPS. Compliance with these policies is included in the independent audit requirements described in section 7. 4.1.1. Site location and construction The Root Zone Key Signing Key operations are conducted within physically protected environments that deter, prevent, and detect any unauthorized use of, access to, or disclosure of sensitive information and systems, whether covert or overt. The RZ KSK Operator maintains disaster recovery capabilities for its DNSSEC operations by maintaining more than one site with comparable physical security. 4.1.2. Physical access The RZ KSK Operator's signer systems are protected by a minimum of four tiers of physical security, with access to lower tiers required before gaining access to higher tiers. Progressively more restrictive physical access controls to each tier are applied. Unauthorized access becomes increasingly difficult as one reaches higher tiers. Sensitive DNSSEC operational activity and any activity related to the lifecycle of the RZ KSK occur within these restrictive physical tiers. Physical access is automatically logged and video recorded. All tiers enforce individual access control through the use of two-factor authentication. Unescorted personnel, including visitors or [Page 12] Root Zone KSK Operator DPS April 2020 employees without specific authorization, are not allowed into such secured areas. The physical security system includes additional controls for tiers used for key management activity which serves to protect storage of Hardware Security Modules (HSMs) and keying material. Areas used to create and store cryptographic material enforce dual access control, each through the use of two-factor authentication. HSMs are protected through the use of tamper-evident bags, locked safes, cabinets and containers. Access to HSMs and keying material is restricted in accordance with the RZ KSK Operator's segregation of duty requirements. The opening and closing of cabinets or containers in these tiers is logged for auditing purposes. 4.1.3. Power and air conditioning The RZ KSK Operator's secure facilities are equipped with primary and backup power systems to ensure continuous, uninterrupted access to electric power and backup heating/ventilation/air conditioning systems to control temperature and relative humidity. 4.1.4. Water exposures The RZ KSK Operator has taken reasonable precautions to minimize the impact of water exposure to the signer systems. 4.1.5. Fire prevention and protection The RZ KSK Operator has taken reasonable precautions to prevent and extinguish fires or other damaging exposure to flame or smoke. The RZ KSK Operator's fire prevention and protection measures have been designed to comply with local fire safety regulations. 4.1.6. Media storage All media containing production software and data, audit, archive, or backup information are stored within the RZ KSK Operator's facilities or in a secure off-site storage facility with appropriate physical and logical access controls designed to limit access to authorized personnel and protect such media from accidental damage (e.g., water, fire and electromagnetic radiation). 4.1.7. Waste disposal Sensitive documents and materials are shredded before disposal. Media used to collect or transmit sensitive information are rendered unreadable before disposal. Cryptographic devices are physically destroyed or zeroized in accordance with the manufacturers' guidance [Page 13] Root Zone KSK Operator DPS April 2020 prior to disposal. Other waste is disposed of in accordance with the RZ KSK Operator's normal waste disposal requirements. 4.1.8. Off-site backup The RZ KSK Operator performs routine backups of critical system data, audit log data, and other sensitive information. Off-site backup media are stored in a physically secure manner using a bonded third party storage facility. 4.2. Procedural Controls 4.2.1. Trusted roles The RZ KSK Operator considers the categories of personnel identified in this section as Trusted Persons having a Trusted Role. A Trusted Person may only possess one Trusted Role. Persons seeking to become Trusted Persons by obtaining a Trusted Role must successfully complete the screening requirements set out in this DPS. Trusted Persons include all employees, contractors, and consultants of either PTI or ICANN that have access to or control operations that may materially affect: o Generation and protection of the private component of the Root Zone Key Signing Key. o Secure export or import of any public components. o Zone File data. Trusted roles include, but are not limited to: o System Administrators o Crypto Officers o Recovery Key Share Holders o Safe Security Controllers o Internal Witnesses o Ceremony Administrators [Page 14] Root Zone KSK Operator DPS April 2020 4.2.2. Number of persons required per task The RZ KSK Operator has established, maintains, and enforces rigorous control procedures to ensure the segregation of duties based on roles and to ensure that multiple Trusted Persons are required to perform sensitive tasks. The most sensitive tasks, such as access to and management of cryptographic key material, are enforced by rigorous control procedures to ensure the segregation of duties based on roles. These procedures also ensure that multiple Trusted Persons are required to perform any sensitive tasks. Access to and management of cryptographic hardware is based on the principle of successive barriers in three tiers, requiring at least seven trusted persons from four different roles. These barriers are as follows: Tier 5: Physical access to safe room requires one person from the Key Ceremony Administrator role in combination with one person from the Internal Witness roles. Tier 6: Physical access to cryptographic hardware (HSM) and activation material requires one out of two of the Safe Security Controller #1s, and one out of the two Safe Security Controller #2s in addition to the Trusted Persons required at Tier 5 and 7. Tier 7: Activation of a HSM requires three out of seven Crypto Officers to extract activation material from above safe deposit boxes using their physical key. Safe deposit box operation that involves opening of any one of the deposit box requires three out of seven Crypto Officers to be present. Restoration of the contents of a HSM requires at least six trusted persons from two different roles, as follows: Secret share: Reconstruction of the secret key used for encryption of the application keys requires five out of seven Recovery Key Share Holders. Encrypted application keys: Physical access to the encrypted application keys requires one person from the Ceremony Administrators role, one person from [Page 15] Root Zone KSK Operator DPS April 2020 the Internal Witness role, and one of two Safe Security Controller #1s. These combinations of people are designed so that the binomial probability to find a group collaborating in any of these constellations is less than one in a million, assuming a dishonesty rate of 5% among Trusted Persons Other internal control procedures are designed to ensure that at a minimum of two Trusted Persons are required to perform any sensitive task. 4.2.3. Identification and authentication for each role For all personnel seeking to become Trusted Persons, verification of identity is performed through the personal (physical) presence of such personnel before Trusted Persons performing security functions and a check of well-recognized forms of identification (e.g., passports and driver's licenses). Identity is further confirmed through the background checking procedures described in section 4.3 of this DPS. The RZ KSK Operator ensures that personnel have achieved Trusted Status and approval has been given before these personnel are: o issued access devices and granted access to the required facilities, o issued electronic credentials to access and perform specific functions on the RZ KSK Operator's IT systems. 4.2.4. Tasks requiring separation of duties Tasks requiring separation of duties include (but are not limited to) the generation, use and destruction of Root Zone DNSSEC key material. Personnel holding a role in the multi-party access to the RZ KSK do not hold a role in the multi-party access to the RZ ZSK, or vice versa. Audit personnel also may not participate in the multi-person control for the RZ KSK or RZ ZSK. 4.3. Personnel Controls 4.3.1. Qualifications, experience, and clearance requirements The RZ KSK Operator requires that personnel seeking to become Trusted Persons present proof of the requisite background, qualifications, [Page 16] Root Zone KSK Operator DPS April 2020 and experience needed to perform their prospective job responsibilities competently and satisfactorily. Background checks are repeated at least every 5 years for personnel holding Trusted Roles. 4.3.2. Background check procedures All personnel with access to any cryptographic components used with the Root Zone Signing process are required to pass a background check extending back at least three years. Prior to commencement of engagement in a Trusted Role, the RZ KSK Operator conducts background checks that include the following: o Confirmation of previous employment o Check of professional references o Confirmation of the highest or most relevant educational degree obtained o Check of credit/financial records to the extent allowed by national laws for the individual's country of residence The factors revealed in a background check that may be considered grounds for rejecting candidates for Trusted Roles, or for taking action against an existing Trusted Person generally include, but are not limited to: o Misrepresentations made by the candidate or Trusted Person o Highly unfavorable or unreliable professional references o Indications of a lack of financial responsibility Reports containing such information are evaluated by human resources and security personnel, who determine the appropriate course of action in light of the type, magnitude, and frequency of the behavior uncovered by the background check. Such actions may include measures up to and including the cancellation of offers of employment made to candidates for Trusted Roles or the termination of existing Trusted Persons. The use of information revealed in a background check to take such actions is subject to the applicable federal, state, and local laws. [Page 17] Root Zone KSK Operator DPS April 2020 4.3.3. Training requirements The RZ KSK Operator provides its personnel with training when hired, as well as the requisite on-the-job training needed for them to perform their job responsibilities competently and satisfactorily. The RZ KSK Operator periodically reviews and enhances its training programs as necessary. The RZ KSK Operator's training programs are tailored to the individuals' responsibilities and include the following as relevant: o Basic DNS/DNSSEC concepts o Job responsibilities o Use and operation of deployed hardware and software o Security and operational policies and procedures o Incident and compromise reporting and handling o Disaster recovery and business continuity procedures 4.3.4. Retraining frequency and requirements The RZ KSK Operator provides refresher training and updates to their personnel to the extent and frequency required to ensure that such personnel maintain the required level of proficiency to perform their job responsibilities competently and satisfactorily. 4.3.5. Job rotation frequency and sequence The responsibility to execute the tasks of respective Trusted Roles will be distributed evenly over the set of the appointed personnel. Recovery Key Share Holders and Crypto Officers will be serving limited terms. Refer to Trusted Community Representatives - Proposed Approach to Root Key Management [TCRS] for the original proposal for TCR participation. Other positions are rotated and replaced as needed. [Page 18] Root Zone KSK Operator DPS April 2020 4.3.6. Sanctions for unauthorized actions Appropriate disciplinary actions are taken for unauthorized actions with respect to this DPS and/or other violations of the RZ KSK Operator's security policies and procedures. Disciplinary actions may include measures up to and including termination and are commensurate with the frequency and severity of the unauthorized actions. 4.3.7. Contracting personnel requirements In limited circumstances, independent contractors or consultants may be used to fill Trusted Roles. Any such contractor or consultant is held to the same functional and security criteria that apply to any PTI and ICANN employees in a comparable role. Independent contractors and consultants who have not completed or passed the background check procedures specified in DPS section 4.3 are permitted access to the RZ KSK Operator's secure facilities only to the extent they are escorted and directly supervised by Trusted Persons at all times. 4.3.8. Documentation supplied to personnel PTI and ICANN provide their employees the requisite training and other documentation needed to perform their job responsibilities competently and satisfactorily. 4.4. Audit Logging Procedures 4.4.1. Types of events recorded Specific auditing events related to KSK key life cycle management events, including: o Key generation, backup, storage, recovery, archival, and destruction. o Exporting of public key components. KSK signing and management events, including: o Key activation o Receipt and validation of public key material (i.e., from the ZSK holder) [Page 19] Root Zone KSK Operator DPS April 2020 o Successful or unsuccessful signing requests Security-related events, including: o Assignment and revocation of credentials o Successful and unsuccessful system access attempts o Key and security system actions performed by trusted personnel o Security sensitive files or records read, written or deleted o Security profile changes o System crashes, hardware failures and other anomalies o Facility visitor entry/exit o System changes and maintenance/system updates o Incident response handling Log entries include the following elements: o Date and time of the entry o Identity of the entity making the journal entry o Type of entry Other events as appropriate. 4.4.2. Frequency of processing log Audit logs are examined after each key ceremony for significant security and operational events. In addition, the RZ KSK Operator reviews its audit logs for suspicious or unusual activity in response to alerts generated based on irregularities and incidents within the DNSSEC related systems. Audit log processing consists of a review of the audit logs and documentation for all significant events in an audit log summary. Audit log reviews include a verification that the log has not been tampered with and an investigation of any alerts or irregularities in the logs. Actions taken based on audit log reviews are also documented. [Page 20] Root Zone KSK Operator DPS April 2020 4.4.3. Retention period for audit log information All audit data collected in terms of section 4.4.1 is retained on- site for at least one year after creation and then archived for at least 10 years. The media holding the audit data and the applications required to process the information are maintained to ensure that the archived data can be accessed for the time period set forth in this DPS. 4.4.4. Protection of audit log Audit logs are kept off-line and protected with an audit log handling procedure that includes mechanisms to protect the log files from unauthorized viewing, modification, deletion, or other tampering. Only authorized Trusted Persons are able to obtain direct access to the audit information. 4.4.5. Audit log backup procedures The RZ KSK Operator backs up electronic archives of its audit information in an off-site secure facility after each key ceremony. Copies of paper-based records are also stored off-site and are maintained in the same manner. 4.4.6. Audit collection system Automated audit data is generated and recorded at the application and operating system level. Manually generated audit data is recorded by the Ceremony Administrator on paper. After each completed Key Ceremony, the audit log information is collected by the Ceremony Administrator at the generating host and copied onto at least two portable media. Electronic copies of paper- based documents are also made. The Ceremony Administrator is responsible for storing one copy of the audit log information at the off-site secure facility, and one copy with the signer system. 4.4.7. Notification to event-causing subject No notice is required to be given to the individual, organization, device, or application causing a log event. [Page 21] Root Zone KSK Operator DPS April 2020 4.4.8. Vulnerability assessments Events in the audit process are logged, in part, to monitor system vulnerabilities. Vulnerability assessments are performed manually as part of the audit log review process after each key ceremony. The RZ KSK Operator also maintains contacts with relevant parties within the community to share the latest security-related information which may affect the signed root zone. Continuous vulnerability assessments are made based on this information. 4.5. Compromise and Disaster Recovery 4.5.1. Incident and compromise handling procedures If the RZ KSK Operator detects an event that has lead to, or could have lead to a security compromise of any of the security mechanisms, it will perform an investigation in order to determine the nature of the incident. If the incident is suspected to have compromised the private component of an active KSK, the Emergency KSK roll-over procedure will be enacted as described in section 4.5.3. Otherwise, the scope, severity and damage of the incident will be assessed and a plan to remedy the effect will be developed and implemented. The plan will also include measures to prevent the event from reoccurring. The incident handling procedures include reporting of all events to RZ KSK Operations Security (RKOS), which in turn reports to the RZ KSK Policy Management Authority (PMA). 4.5.2. Corrupted computing resources, software, and/or data In the event of the corruption of computing resources, software, and/ or data, this occurrence will be reported to RKOS and will cause the RZ KSK Operator's incident handling procedures to be enacted. Such procedures require appropriate escalation, incident investigation, and incident response. If necessary, the RZ KSK Operator's key compromise or disaster recovery procedures will be enacted as described in section 4.5.4 and 4.5.3. 4.5.3. Entity private key compromise procedures 4.5.3.1. Key Signing Key compromise The RZ KSK Operator has established and maintains Emergency KSK roll- over procedures to ensure readiness for key compromise situations. [Page 22] Root Zone KSK Operator DPS April 2020 Upon the suspected or known compromise of a Root Zone Key Signing Key, RKOS will assess the situation, develop an appropriate action plan, and implement the action plan with approval from the PMA and PTI executive management. As part of the KSK emergency roll-over procedures, the RZ KSK Operator maintains the capability of being able to generate and publish an interim Trust Anchor within 48 hours. In favorable circumstances, this interim Trust Anchor may be used to facilitate an orderly RFC 5011 [RFC5011] automatic KSK roll-over to a new and sanctioned Trust Anchor generated at a new scheduled key ceremony, held within reasonable time. The RZ KSK Operator will inform the community of any emergency as soon as possible using the channels stipulated in section 2.1. 4.5.3.2. Key Signing Key loss If the private component of a Trust Anchor is permanently lost, the latest point in time where this loss is detected will inevitably be at the key ceremony when it is supposed to be used. At this point in time, the Root Zone Maintainer/ZSK Operator has signatures for at least 33 days (see 6.6) of independent operations. If possible, a new KSK will be generated at this key ceremony or another ceremony scheduled within 48 hours. If the RZ KSK Operator is unable to accommodate the key ceremony, an interim KSK must be generated by the RZ KSK Operator and published as a Trust Anchor within the stipulated 48 hours. The community is then given a minimum of 30 days notice to add the new Trust Anchors to the validating resolvers before the DNSKEY RRset has to be re-signed with the new Trust Anchor. Failure to update a validating resolver will render that resolver inoperable. The RZ KSK Operator will inform the community of any emergency as soon as possible using the channels stipulated in section 2.1. The old Trust Anchor will remain untouched in the key set for one 10 day time slot (see section Section 6.6). In the next consecutive time slot the old Trust Anchor will be marked as revoked, and after this time slot the lost key is permanently removed. 4.5.3.3. Zone Signing Key Compromise The RZ KSK Operator will support Root Zone Zone Signing Key emergency rollover in the case of RZ ZSK compromise while following the RZ ZSK [Page 23] Root Zone KSK Operator DPS April 2020 Operator's procedural directions. Refer to the RZ ZSK Operator's DPS for details. 4.5.4. Business Continuity and IT Disaster Recovery Capabilities The RZ KSK Operator has implemented at least two fully-functional, geographically and logically dispersed sites, which at any point in time hold the data required for production, and are evenly utilized. All sites implements the same physical security protections and operational controls as specified in 4.1.2. The RZ KSK Operator has developed, implemented and tested a business continuity and IT disaster recovery plan to mitigate the effects of natural, man-made, or technological disasters or other disasters that requires temporary or permanent cessation of operations from any of the RZ KSK Operator's facilities. The business continuity and IT disaster recovery plans are in place to address the restoration of information systems services and key business functions. These plans address: o Roles and responsibilities in the event of a disaster. o Fallback procedures for restoring business-critical processes within acceptable times. o Resumption procedures for restoring normal operations. o The criteria for activating the plan. The RZ KSK Operator maintains the capability to restore or recover essential operations within 48 hours following a disaster with support for at minimum the following functions: o Communication with the public. o Ability to import KSRs (Key Signing Requests) and export SKRs (Signed Key Responses). o Generation of Key Signing Keys. o Processing and signing of KSR contents. o Publishing the Trust Anchor. The RZ KSK Operator maintains redundant hardware and backups of its infrastructure system software at all sites. In addition, private [Page 24] Root Zone KSK Operator DPS April 2020 keys are backed up and maintained in accordance with DPS section 5.2.4, and in such a way that critical keying material is distributed to all sites before put into production. The RZ KSK Operator's business continuity and IT disaster recovery plans have been designed to provide full recovery within one week at the alternative site following any incident or disaster occurring at any of the RZ KSK Operator's sites. When possible, operational status is restored as soon as possible following any incident or disaster. These plans are regularly tested, validated, and updated to be operational in the event of any incident or disaster. Results of such tests are reviewed and kept for audit and planning purposes. 4.5.4.1. Variances In the event of a declaration of a disaster recovery or business continuity response, the adverse event may necessitate variances to the procedural controls and technical security controls. These variances shall be limited in scope to those necessary for the successful conduct of key signing operations, and according to protocols that best ensures a proper record of the chain-of-custody and limiting sensitive operations to trusted persons. The RZ KSK Operator shall ensure such variances are consented by the RZ KSK Operator's management, are documented and communicated. 4.6. Entity termination The RZ KSK Operator has implemented a DNSSEC termination plan in the event that the roles and responsibilities of the Root Zone KSK Operator must transition to other entities. The Root Zone Manager will coordinate with the Root Zone ZSK Operator in order to execute the transition in a secure and transparent manner. The DNSSEC termination plan also includes procedures in the event of the termination of the Root Zone Maintainer and/or Root Zone ZSK Operator. 5. TECHNICAL SECURITY CONTROLS 5.1. Key Pair Generation and Installation [Page 25] Root Zone KSK Operator DPS April 2020 5.1.1. Key pair generation Root Zone (RZ) Key Signing Key (KSK) key pair generation is performed by multiple pre-selected, trained and trusted individuals using Trustworthy Systems and processes that provide for the security and required cryptographic strength for the generated keys. All KSK key pairs are generated in pre-planned Key Generation Ceremonies in accordance with the requirements of the Key Ceremony Reference Guide. The activities performed in each key generation ceremony are recorded, dated and signed by the Ceremony Administrator. These records are kept for audit and tracking purposes as required in section 4.4.3. 5.1.2. Public key delivery The public component of a Trust Anchor will be distributed in a secure fashion to preclude substitution attacks. Acceptable methods for delivery and validation of Trust Anchors include, but are not limited to: o In-band as zone data in DNSKEY RRset, with proof traceable to the previous Trust Anchor as described in RFC 5011 [RFC5011]. o Publication of the Trust Anchor in the repository, protected and authenticated via TLS/SSL, while also providing S/MIME [RFC5751] and other signatures traceable to the RZ KSK Operator and optionally other parties. o Proof distributed out-of-band directly to the witnesses participating at the key ceremony, whereas distribution to their respective communities at the witness' own discretion. 5.1.3. Public key parameters generation and quality checking For the current key size, primality testing of RSA parameters (p and q) will be performed to ensure with a probability less than 2^-100 that the numbers are not composite. Quality checking will also include validating the size of the public exponent to be both resource efficient and secure. [Page 26] Root Zone KSK Operator DPS April 2020 5.1.4. Key usage purposes Any root zone KSK private key will only be used for signing the root zone's DNSKEY RRset or self-signing using the same padding scheme in order to prove possession of the private key. Any RRSIG record generated as a result of a KSK signing operation will not have a validity period longer than 21 days, and will never expire more than 180 days in the future. Disaster recovery procedures may override the previously defined RRSIG expiration period if reasonable concerns exist that a subsequent key signing ceremony is not possible in its allotted window. Any additional RRSIG records generated in advance of the standard validity period remain in the possession of the RZ KSK Operator until the time in which all RRSIG records in the set would not expire more than 180 days in the future. 5.2. Private key protection and Cryptographic Module Engineering Controls All cryptographic functions involving the private component of the KSK are performed within the HSM; that is, the private component will not be exported from the HSM except in encrypted form for purposes of key backup. 5.2.1. Cryptographic module standards and controls For RZ KSK generation and RZ KSK private component operations and storage, the RZ KSK Operator uses hardware security modules that are validated at FIPS 140-2 level 4 overall. 5.2.2. Private key (m-of-n) multi-person control The RZ KSK Operator has implemented technical and procedural mechanisms that require the participation of multiple trusted individuals to perform sensitive cryptographic operations. The RZ KSK Operator splits activation data needed to make use of the RZ KSK private key onto separate smartcards controlled by trusted individuals (Crypto Officers) selected from members of the Internet community not already part of root zone management operations. Specifically, organizationally separate parties, not affiliated with PTI, ICANN or Verisign. A threshold number of smartcards (m) out of the total number of smartcards created and distributed for a particular hardware security module (n) is required to activate a RZ KSK private key stored on the module. The threshold number of cards needed to sign using the RZ [Page 27] Root Zone KSK Operator DPS April 2020 KSK is three out of seven. The smartcards are protected in accordance with Section 5.4.2. 5.2.3. Private key escrow Private components of Root Zone Key Signing Keys are not escrowed. 5.2.4. Private key backup Encrypted copies of the RZ KSK private key(s) are backed up onto portable media held by the RZ KSK Operator and sent by courier to the other facilities. The key used to encrypt the private key(s) is backed up using a five out of seven threshold scheme with smartcards distributed to trusted individuals (Recovery Key Share Holders) selected from members of the Internet community not already part of root zone management operations (specifically, organizationally separate parties, not affiliated with PTI, ICANN or Verisign). The Recovery Key Share Holders keep the cards in tamper-evident bags, stored in geographically dispersed locations under their control. 5.2.5. Private key storage on cryptographic module Private keys held on hardware cryptographic modules are stored in encrypted form. 5.2.6. Private key archival The private half of the RZ KSK key pair is not archived after rollover. This eliminates the possibility of its misuse in RZ KSK rollover or revocation after its suppression. 5.2.7. Private key transfer into or from a cryptographic module The RZ KSK Operator generates RZ KSK key pairs on the hardware security modules in which the keys will be used. In addition, the RZ KSK Operator makes copies of these key pairs for routine recovery and disaster recovery purposes. When key pairs are backed up to another hardware security module, these key pairs are transported between modules in encrypted form. 5.2.8. Method of activating private key The RZ KSK private key will be activated using three out of seven Crypto Officer controlled smartcards that must be inserted into the HSM, one at a time, while entering the Crypto Officers' PIN. [Page 28] Root Zone KSK Operator DPS April 2020 5.2.9. Method of deactivating private key The RZ KSK private key may be deactivated by three out of seven Crypto Officer controlled smartcards being inserted into the HSM, one at a time, while entering the Crypto Officers' common PIN. The cards that were not used to activate the RZ KSK private key in the ceremony will be preferentially used for deactivation. Alternatively, the RZ KSK private keys may be deactivated upon system shutdown. 5.2.10. Method of destroying private key When required, the RZ KSK Operator destroys RZ KSK private keys in a manner that reasonably ensures that there are no residual remains of the keys that could lead to the reconstruction of the keys. The RZ KSK Operator utilizes the zeroization function of its hardware security modules and other appropriate means to ensure the complete destruction of RZ KSK private keys. When performed, private key destruction activities are logged as part of a key ceremony. 5.3. Other Aspects of Key Pair Management 5.3.1. Public key archival RZ KSK public keys are backed up and archived. 5.3.2. Key usage periods The Operational Period of a RZ KSK ends upon its supersession. The superseded RZ KSK will never be reused to sign a resource record while in retention. 5.4. Activation data 5.4.1. Activation data generation and installation Activation data used to protect access to hardware security modules (HSM) containing RZ KSK private keys is generated in accordance with the requirements of DPS section 5.1 and the Key Ceremony Reference Guide. The creation and distribution of these smartcards and/or access to them is logged. 5.4.2. Activation data protection Crypto Officers safeguard the credentials needed to access activation data. [Page 29] Root Zone KSK Operator DPS April 2020 When required, activation data will be decommissioned using methods that protect against the loss, theft, modification, unauthorized disclosure, or unauthorized use of the private keys protected by this activation data. 5.4.3. Other aspects of activation data Each Crypto Officer holds a physical key to one safe deposit box located inside a safe within the RZ KSK Operator's safe room. This safe deposit box contains the Crypto Officer's card stored in a tamper-evident bag with an individual ID. It is the Crypto Officer's responsibility to safeguard and securely store their physical key between key ceremonies. 5.5. Computer Security Controls The RZ KSK Operator ensures that the systems maintaining key software and data files are Trustworthy Systems secure from unauthorized access. In addition, the RZ KSK Operator limits access to production servers to those individuals with a valid business reason for such access. General application users do not have accounts on production servers. 5.6. Network Security Controls No part of the signer system making use of the HSM is connected to any communications network. Communication of ZSK key signing requests (KSR) from the Root Zone Maintainer/ZSK Operator is done using a TLS client-side authenticated web server connected to the RZ KSK Operator's production network. Transfer of a KSR from the web server to the signer system is performed manually using removable media (refer to Section 6.7 for further details on verification of the KSR). The RZ KSK Operator's production network is logically separated from other components. This separation prevents network access except through defined application processes. The RZ KSK Operator uses firewalls to protect the production network from internal and external intrusion and limit the nature and source of network activities that may access production systems that are related to key signing activities. 5.7. Timestamping Time will be derived through a manual procedure before each key ceremony. The ceremony administrator will manually set the signer system clock and the wall clock to current UTC time drawn from a reliable time source. [Page 30] Root Zone KSK Operator DPS April 2020 Time derived from the procedure will be used for timestamping of o electronic and paper based audit log records o DNSSEC signatures expiration and inception times Asserted times are required to be accurate within three minutes. 5.8. Life Cycle Technical Controls 5.8.1. System development controls The RZ KSK Operator's Software Development Life-Cycle (SDLC) procedures for the Root Zone KSK key generation and signer software implements relevant parts of NIST SP 800-64 for incorporating security and trustworthiness into the SDLC. In addition, all critical parts of the signers modules developed by the RZ KSK Operator will be subject to external code review. The code review is required to certify that: o There is a documented architectural design describing the security domains and functions maintained by the signer. o The architectural design demonstrates that the signer system prevents bypass of the security-enforcing functionality. o There is a functional specification completely representing the signer system and all operations associated with it. o There is a modular design description and a one-to-one correspondence with the modular decomposition of the implementation. o The implementation representation completely and accurately implements the security-enforcing functions. The RZ KSK Operator developed software, when first loaded, provides a method to verify that the software on the system originated from the RZ KSK Operator, has not been modified prior to installation, and is the version intended for use. [Page 31] Root Zone KSK Operator DPS April 2020 5.8.2. Security management controls The RZ KSK Operator has mechanisms in place to control and monitor the configuration of its systems. The RZ KSK Operator creates a hash of all software packages and software updates. This hash is used to verify the integrity of such software manually. Upon installation and periodically thereafter, the RZ KSK Operator validates the integrity of its systems. 5.8.3. Life cycle security controls The signer system is designed to require a minimum of maintenance. Updates critical to the security and operations of the signer system will be applied after formal testing and approval. The origin of all software and firmware will be securely authenticated by available means. Critical hardware components of the signer system will be procured directly from the manufacturer and transported in tamper-evident bags to their destination in the secure facility. Any hardware will be decommissioned well before the specified life expectancy. 6. ZONE SIGNING The RZ KSK Operator provides the the RZ ZSK Operator with signed and valid DNSSEC RRset for the RZ KSK Operator's current keys and the KSKs. The Root Zone Maintainer includes this keyset into the Root Zone file, adds the Next Secure resource records (NSEC), and creates signatures for all relevant records. The Root Zone is then distributed to the Root Server Operators. The daily Root Zone signing will be conducted semi-automatically by the Root Zone Maintainer's system. 6.1. Key lengths and algorithms Key pairs are required to be of sufficient length to prevent others from determining the key pair's private key using crypto-analysis during the period of expected utilization of such key pairs. The current RZ KSK key pair(s) is an RSA key pair, with a modulus size of 2048 bits. [Page 32] Root Zone KSK Operator DPS April 2020 6.2. Authenticated denial of existence Authenticated denial of existence will be provided through the use of NSEC resource records as specified in RFC 4034 [RFC4034]. 6.3. Signature format The cryptographic hash function used in conjunction with the signing algorithm is required to be sufficiently resistant to preimage attacks during the time in which the signature is valid. The RZ KSK signatures will be generated by encrypting SHA-256 hashes using RSA [RFC5702]. 6.4. Zone signing key roll-over ZSK rollover is carried out quarterly automatically by the Root Zone ZSK Operator's system as described in the Root Zone ZSK Operator's DPS. 6.5. Key signing key roll-over Each RZ KSK will be scheduled to be rolled over through a key ceremony as required, or after 5 years of operation. RZ KSK roll-over is scheduled to facilitate automatic updates of resolvers' Trust Anchors as described in RFC 5011 [RFC5011]. After a RZ KSK has been removed from the key set, it will be retained after its operational period until the next scheduled key ceremony, when the private component will be destroyed in accordance with section 5.2.10. 6.6. Signature life-time and re-signing frequency The signing practice of the Root Zone is divided into quarterly continuous time cycles of approximately 90 days. Time cycles begin on the following dates each year: January 1st April 1st July 1st October 1st [Page 33] Root Zone KSK Operator DPS April 2020 For each of these time cycles there is a key ceremony scheduled during the previous calendar quarter, but no later than 33 days before the time cycle commences. At this key ceremony, all of the necessary RZ KSK operations are performed to enable the Root Zone Maintainer to operate and publish the zone independently throughout the period. To facilitate automatic updates of resolvers' Trust Anchors as described in RFC 5011 [RFC5011] while minimizing the number of keys in the key set, each of the ~90 day time cycles is divided into 10 day slots (9 slots). The time cycle will never last less than 90 days. If the time cycle is more than 90 days, the last slot in the cycle will be expanded to fill the period. For each of these slots there is a pre-generated DNSKEY key set that is signed at the key ceremony with 21 days validity time to allow for signature overlap. The Root Zone Maintainer is responsible for selecting the current key set and publishing it with the corresponding valid signature. | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | RRSIG 1 |---->| RRSIG 2 |---->| RRSIG 3 |---->| RRSIG 4 |---->| RRSIG 5 |---->| RRSIG 6 |---->| RRSIG 7 |---->| RRSIG 8 |---->| RRSIG 9 |---->| DNSKEY RRSIG's validity period within the cycle Figure 1 The Root Zone Maintainer may use slots at the edge of every time cycle for pre- and post-publishing at RZ ZSK roll-overs. [Page 34] Root Zone KSK Operator DPS April 2020 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | ZSK n-1 ===|-->| ZSK n ---|===================================|---> ZSK n+1 |---|===> KSK n ===========================|---|++>| KSK n+1 |-------------------|===============> (-) post- or pre-publish (+) revoke bit set (=) used for signing 90 day cycle with ZSK and KSK roll over Figure 2 In the event of a RZ KSK roll-over and RZ ZSK roll-over in the same cycle, time slots are used for pre- and post-publishing, adding and deleting Trust Anchors in the following order: Slot 1: publish ZSK (n) + ZSK (n-1) + KSK (n), sign DNSKEY RRset with KSK(n) Slot 2-6: publish ZSK (n) + KSK (n) + KSK (n+1), sign DNSKEY RRset with KSK(n) Slot 7: publish ZSK (n) + KSK (n) + KSK (n+1), sign DNSKEY RRset with KSK(n+1) Slot 8: publish ZSK (n) + KSK (n+1) + revoked KSK (n), sign DNSKEY RRset with KSK(n+1) Slot 9: publish ZSK (n) + ZSK (n+1) + KSK (n+1), sign DNSKEY RRset with KSK(n+1) At each publication, the Root Zone Maintainer selects and includes the current key set and corresponding signature(s), and then signs all other authoritative records within the root zone using the current RZ ZSK. [Page 35] Root Zone KSK Operator DPS April 2020 6.7. Verification of zone signing key set Each key set within the Key Signing Request (KSR) is self-signed with the active key to provide proof of possession of the corresponding private key. The signer system will automatically validate this signature and perform checking of available parameters before accepting the KSR for signing. The RZ KSK Operator will verify the authenticity of the KSR document by performing an out-of-band verification (verbally over the phone, by fax, or any other available method) of the hash of the KSR, before entering the KSR into the signer system. The resulting Signed Key Response (SKR) is transferred back using the same TLS client-side authenticated connection used to receive the KSR from the Root Zone Maintainer. 6.8. Verification of resource records Signature verification will be performed on the signer system that holds both the signed and the unsigned keyset prior to the compilation of the SKR. Integrity of the signatures in the SKR is verified by the RZ ZSK Operator using the published RZ TA. 6.9. Resource records time-to-live +------------------------+---------------------------------+ | RRtype | TTL | +------------------------+---------------------------------+ | DNSKEY | 48 hours | | NSEC | same as SOA minimum (24 hours) | | Delegation Signer (DS) | 24 hours | | RRSIG | same as the covered RR (varies) | +------------------------+---------------------------------+ 7. COMPLIANCE AUDIT An annual Service Organization Control 3 (SOC 3) audit for DNSSEC operations examination is performed for the Root Zone Key Signing Key operations performed by the RZ KSK Operator. 7.1. Frequency of entity compliance audit Compliance Audits are conducted at least annually at the sole expense of the audited entity. [Page 36] Root Zone KSK Operator DPS April 2020 7.2. Identity/qualifications of auditor The RZ KSK Operator's compliance audits are performed by a public accounting firm that demonstrates proficiency in: o DNSSEC public key infrastructure technology o information security tools and techniques o security auditing o the third-party attestation function and is accredited by the American Institute of Certified Public Accountants (AICPA), which requires the possession of certain skill sets, quality assurance measures such as peer review, competency testing, standards with respect to proper assignment of staff to engagements, and requirements for continuing professional education. 7.3. Auditor's relationship to audited party Compliance audits of the RZ KSK Operators's operations are performed by a public accounting firm that is independent of PTI, ICANN, Verisign and the auditor of Verisign. Third party auditors do not participate in the multi-person control for the RZ KSK. 7.4. Topics covered by audit The scope of the RZ KSK Operator's annual Compliance Audit includes all DNSSEC related procedures such as key environmental controls, key management operations, infrastructure/administrative controls, RZ KSK and signature life cycle management and practices disclosures. 7.5. Actions taken as a result of deficiency With respect to compliance audits of the RZ KSK Operator's operations, significant exceptions or deficiencies identified during the Compliance Audit will result in a determination of actions to be taken. Such determinations are made by the RZ KSK Operator's management with input from the auditor. The RZ KSK Operator's management is responsible for developing and implementing a corrective action plan. If the RZ KSK Operator determines that such exceptions or deficiencies pose an immediate threat to the security or integrity of the RZ KSK, a corrective action plan will be developed within 30 days and implemented within a commercially reasonable period of time. For less serious exceptions or deficiencies, the RZ KSK Operator's Management will evaluate the [Page 37] Root Zone KSK Operator DPS April 2020 significance of such issues and determine the appropriate course of action. 7.6. Communication of results A copy of the RZ KSK Operator's Compliance Audit report and Management's Assertion letter can be found at 8. LEGAL MATTERS 8.1. Fees No fees are charged for acceptance, signing and publishing of Delegation Signer resource records, or any other function related to DNSSEC. 8.2. Financial responsibility PTI and ICANN accept no financial responsibility for improper use of Trust Anchors or signatures issued under this DPS. 8.3. Confidentiality of business information 8.3.1. Scope of confidential information The following records shall be kept confidential and private (Confidential/Private Information): o Private keys and information needed to recover such private keys o Signatures of key sets to be published in the future o Transactional records (both full records and the audit trail of transactions) o Audit trail records created or retained by the RZ KSK Operator or the RZ ZSK Operator o Audit reports created by the RZ KSK Operator or the RZ ZSK Operator (to the extent such reports are maintained), or their respective auditors (whether internal or public), until such reports are made public o Contingency planning and disaster recovery plans [Page 38] Root Zone KSK Operator DPS April 2020 o Security measures controlling the operations of the RZ KSK Operator's hardware and software and the administration of DNS Keys 8.3.2. Information not within the scope of confidential information All information pertaining to the database of top-level domains is public information, such as Public Keys, Key Revocation information, and other status information. These repositories and the information contained within them are not considered Confidential/Private Information. 8.3.3. Responsibility to protect confidential information Not applicable 8.4. Privacy of personal information 8.4.1. Information treated as private Not applicable 8.4.2. Types of information not considered private Not applicable 8.4.3. Responsibility to protect private information Not applicable 8.4.4. Disclosure Pursuant to Judicial or Administrative Process The RZ KSK Operator shall be entitled to disclose Confidential/ Private Information if, in good faith, the RZ KSK Operator believes that disclosure is necessary in response to judicial, administrative, or other legal process during the discovery process in a civil or administrative action, such as subpoenas, interrogatories, requests for admission, and requests for production of documents. 8.5. Limitations of liability The RZ KSK Operator shall not be liable for any financial loss, or loss arising from incidental damage or impairment, resulting from its performance of its obligations hereunder. No other liability, implicit or explicit, is accepted. [Page 39] Root Zone KSK Operator DPS April 2020 8.6. Term and termination 8.6.1. Term The DPS, and any subsequent amended versions, becomes effective upon publication in the Root Zone KSK Operator's repository. 8.6.2. Termination This DPS is amended from time-to-time and will remain in force until it is replaced by a new version. 8.6.3. Dispute resolution provisions Disputes among DNSSEC participants shall be resolved pursuant to provisions in the applicable agreements among the parties. 8.6.4. Governing law This DPS shall be governed by the laws of the State of California. 9. References 9.1. Normative References [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, September 2007, . [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, DOI 10.17487/RFC5702, October 2009, . 9.2. Informative References [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [Page 40] Root Zone KSK Operator DPS April 2020 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, . [RFC7958] Abley, J., Schlyter, J., Bailey, G., and P. Hoffman, "DNSSEC Trust Anchor Publication for the Root Zone", RFC 7958, DOI 10.17487/RFC7958, August 2016, . [TCRS] Lamb, R., "Trusted Community Representatives -- Proposed Approach to Root Key Management", April 2010. Appendix A. Table of acronyms and definitions A.1. Acronyms +--------+----------------------------------------------------------+ | Term | Definition | +--------+----------------------------------------------------------+ | AD | Authenticated Data Flag | | AICPA | American Institute of Certified Public Accountants | | BIND | Berkley Internet Name Domain | | CC | Common Criteria | | CD | Checking Disabled | | DNS | Domain Name System | | DNSKEY | Domain Name System Key | | DNSSEC | Domain Name System Security Extensions | | DO | DNSSEC OK | | DPS | DNSSEC Policy and Practices Statement | | DS | Delegation Signer | | EAL | Evaluation Assurance Level (pursuant to the Common | | | Criteria) | | FIPS | Federal Information Processing Standards | | FISMA | Federal Information Security Management Act | | HSM | Hardware Security Module | | IANA | Internet Assigned Numbers Authority | | ICANN | Internet Corporation for Assigned Names and Numbers | | IETF | Internet Engineering Task Force | | ISO | International Organization for Standardization | | NIST | National Institute of Standardization of Technology | | NS | Name Server | | NSEC | NextSecure | [Page 41] Root Zone KSK Operator DPS April 2020 | NSEC3 | Hashed NextSecure | | PKI | Public Key Infrastructure | | PMA | Policy Management Authority | | RFC | Request for Comments | | RZ | Root Zone | | KSKO | Key Signing Key Operator | | PTI | Public Technical Identifiers | | RKOS | Root Zone KSK Operations Security | | RRSIG | Resource Record Signature | | RZMS | Root Zone Management System | | SEP | Secure Entry Point | | SHA | Secure Hash Algorithm | | SKR | Signed Key Responses | | SOA | Start of Authority | | SP | NIST Special Publication | | TA | Trust Anchor | | TLD | Top Level Domain | | TSIG | Transaction Signature | | TTL | Time To Live | | VERT | Verisign Emergency Response Team | | VRSN | Verisign, Inc. | | VSIRT | Verisign Security Incident Response Team | | ZSKO | Zone Signing Key Operator | +--------+----------------------------------------------------------+ A.2. Definitions +----------------+--------------------------------------------------+ | Term | Definition | +----------------+--------------------------------------------------+ | Chain of Trust | DNS keys, signatures, and delegation signer | | | records that, when validated in a series, can | | | provide proof of authenticity of the last | | | element in the chain using the first element in | | | the chain. Usually, the first element is a | | | trust anchor. | | Compromise | A violation (or suspected violation) of a | | | security policy, in which an unauthorized | | | disclosure of, or loss of control over, | | | sensitive information may have occurred. With | | | respect to private keys, a compromise is a loss, | | | theft, disclosure, modification, unauthorized | | | use, or other compromise of the security of such | | | private key. | | Compliance | A periodic review that an entity undergoes to | | Audit | determine its conformance with standards that | | | apply to it. | | Delegation | Delegation Signer is one of the resource records | [Page 42] Root Zone KSK Operator DPS April 2020 | Signer (DS) | indicating that the delegated zone is digitally | | | signed. It also assures that the parent zone | | | recognizes the indicated key for the delegated | | | zone. Refer to [RFC4035] for the formal | | | definition. | | Hardware | A type of secure cryptoprocessor aimed at | | Security | managing cryptographic keys and cryptographic | | Module (HSM) | operations while providing physical protection | | | of the private keying material through | | | mechanisms to detect and protect against | | | tampering. | | Key Generation | A procedure whereby a key pair is generated, its | | Ceremony | private key is transferred into a cryptographic | | | module, its private key is backed up, and/or key | | | sets are signed. | | Key Signing | A key that signs the key set. | | Key (KSK) | | | Management | Compliance Audit of the entity or as part of the | | Review | overall risk management process in the ordinary | | | course of business. | | Offline HSM | HSMs that are maintained offline for security | | | reasons in order to protect them from possible | | | attacks by intruders by way of the network. | | | These HSMs do not directly sign. | | Online HSM | HSMs that sign the Zone file under the Zone | | | Signing Key are maintained online so as to | | | provide continuous signing services. | | Parent Zone | The zone that is one level higher in the DNS | | | hierarchy. | | Public Key | The architecture, organization, techniques, | | Infrastructure | practices, and procedures that collectively | | | support the implementation and operation of a | | | public key cryptographic system. | | Regulated | A financial institution that is regulated, | | Financial | supervised, and examined by governmental, | | Institution | national, state or provincial, or local | | | authorities having regulatory authority over | | | such financial institution based on the | | | governmental, national, state or provincial, or | | | local laws under which such financial | | | institutions was organized and/or licensed. | | Repository | DNSSEC-related information made accessible | | | online. | | Resource | Signature data in a zone. Refer to [RFC4035] for | | Record | the formal definition. | | Signature | | | (RRSIG) | | | RSA | A public key cryptographic system invented by | [Page 43] Root Zone KSK Operator DPS April 2020 | | Ron Rivest, Adi Shamir, and Leonard Adleman. | | Root Zone KSK | The office within the RZ KSK Operator | | Policy | responsible for promulgating the DPS. | | Management | | | Authority | | | (PMA) | | | Root Zone KSK | A security support and coordination role within | | Operations | the RZ KSK Operator, with the required security | | Security | experience and skills to i.e. provide security- | | (RKOS) | related advice to the PMA, follow up on incident | | | reporting, provide assistance to the external | | | auditors, conduct internal audits, initiate | | | security-awareness activities, provide security | | | training and maintain the Information Security | | | Management System. | | Root Zone | A system used to automate the Root Zone update | | Management | process. | | System (RZMS) | | | Secret Share | A portion of a private key or a portion of the | | | activation data needed to operate a private key | | | under a Secret Sharing arrangement. | | Service | SOC is an assurance service developed by the | | Organization | American Institute of Certified Public | | Control (SOC) | Accountants (AICPA). SOC is designed primarily | | Assurance | to build trust and confidence among businesses | | | depending on systems, addressing areas such as | | | security, availability, confidentiality, and | | | processing integrity. | | Supplemental | A review of an entity by PTI following | | Risk | incomplete or exceptional findings in a | | | Compliance Audit of the entity or as part of the | | | overall risk management process in the ordinary | | | course of business. | | Trust Anchor | A trust anchor is an authoritative entity | | | represented via a public key. A validating | | | security-aware resolver uses this public key as | | | a starting point for building the authentication | | | chain to a signed DNS response. Refer to | | | [RFC4033] for the formal definition of a trust | | | anchor in the context of DNSSEC. | | Trusted Role | A role within the DNSSEC operations that must be | | | held by a Trusted Person. | | Trusted Person | Personnel assigned to a Trusted Role who have | | | successfully completed a a comprehensive | | | background investigation as defined in Section | | | 4.3.2, which indicates their ability to maintain | | | the level of trust necessary for critical DNSSEC | | | operations. | [Page 44] Root Zone KSK Operator DPS April 2020 | Trusted Status | Trusted Status is achieved by a person who has | | | successfully completed the screening | | | requirements for Trusted Roles set out in this | | | DPS. | | Trustworthy | Computer system in which hardware, software, and | | System | operational procedures provide a reasonable (1) | | | security against intrusion, misuse, unauthorized | | | access, (2) degree of availability, and (3) | | | adherence to accepted security practices. | | Verisign | Means, with respect to each pertinent portion of | | | this, Verisign, Inc. and/or any wholly owned | | | Verisign subsidiary responsible for the specific | | | operations at issue. | | Zone | A boundary of responsibility for each domain. | | Zone Signing | A key that signs the Root Zone | | Key (ZSK) | | +----------------+--------------------------------------------------+ Appendix B. History of changes 1st edition (2010-05-21) First edition. 2nd edition (2010-10-21) * Section 1.1: Add further definition to ancillary documents * Section 1.3.8: Add "authenticate" to responsibility of the relying party * Section 2.2: Add reference to Internet Draft to specify trust anchor download methods. 3rd edition (2015-10-01) * Section 1.3.8: Change that relying parties must "stay informed" to "be informed". * Section 2.2: Changed reference to non-specific reference document, as the trust anchor download documents are not finalized. * Section 4.2.2: Expanded definition of the role of cryptographic officers for Tier 7. * Section 5.2.9: Add reference to optional practice of exercising unused CO cards while deactivating the HSM. This [Page 45] Root Zone KSK Operator DPS April 2020 process was added at TCR suggestion as a method of confirming additional CO cards are properly functioning, even if they are not needed for a specific ceremony. * Section 5.4.3: Clarified cryptographic officer method of accessing of smart cards used to activate the HSM. * Minor editorial and layout changes: Updated contact details including ICANN's corporate address; Updated references to "VeriSign" to "Verisign" to reflect company's name capitalization change; Updated copyright notice on document; Convert authors to acknowledgements section, with document controller (ICANN PMA) listed as editor. 4th edition (2016-10-01) * Significant changes throughout to reflect the operation of the Root Zone Key Signing Key by the new entity PTI, which is transferred responsibility for the managing the DNS Root Zone and the Root Zone Key Signing Key as of 2016-10-01 from ICANN. The role of the US Government in KSK operations is also concluded. * Section 5.1.2: Remove OpenPGP as a method for validation of the trust anchor. * Sections 5.1.4, 6.6: Change signature validity period to 21 days to implement RSSAC 003 guidance. 5th edition (2020-04-07) * Section 4.2.2: Updated Personnel requirements. * Section 4.5.4.1: Variances created to explain deviations of standard procedure in the event of a disaster recovery scenario. * Section 5.1.4: Key usage updated to cover disaster scenario where additional RRSIG records may be generated. * Section 6.6: Updated key ceremony scheduling requirements. * Overall: Formatting and grammatical improvements. [Page 46] Root Zone KSK Operator DPS April 2020 Appendix C. Acknowledgments This document was initially the product of the Root DNSSEC Design Team convened between ICANN, Verisign and the US Government. It has been maintained by the Root Zone KSK Policy Management Authority, based on experience as well as feedback from the community. Of particular note, the first edition of this document was principally authored by Fredrik Ljunggren, Tomofumi Okubo, Richard Lamb and Jakob Schlyter. Author's Address Root Zone KSK Policy Management Authority 12025 Waterfront Drive, Suite 300 Los Angeles 90094 United States of America Email: root-ksk-pma@iana.org [Page 47]