Skip to main content
Resources

Security, Stability, and Resiliency Review (SSR)

Sign up to learn more

The Board took action on 10 March 2022 to defer the Third Review of Security, Stability and Resiliency of the Domain Name System.  See the Board resolution here.

SSR2 Review Workspace Landing Page
Find the latest status updates, recordings of past meetings, and opportunities to participate
Introduction to Reviews
Learn more about Reviews, their purpose and process for conducting and opportunities to participate
SSR2 Review Meeting Schedule
Find the schedule to observe SSR2 Review Team Meetings
SSR2 Fact Sheet
See the progress of the SSR2 Review Team towards completing the Review
SSR2 Implementation Progress
 

 

Objectives of the SSR Review

Under the Bylaws (Section 4.6(c)), ‘The Board shall cause a periodic review of ICANN’s execution of its commitment to enhance the operational stability, reliability, resiliency, security, and global interoperability of the systems and processes, both internal and external, that directly affect and/or are affected by the Internet’s system of unique identifiers that ICANN coordinates (“SSR Review”).’

The issues that the review team for the SSR Review (“SSR Review Team”) may assess are the following:

  1. security, operational stability and resiliency matters, both physical and network, relating to the coordination of the Internet’s system of unique identifiers;
  2. conformance with appropriate security contingency planning framework for the Internet’s system of unique identifiers;
  3. maintaining clear and globally interoperable security processes for those portions of the Internet’s system of unique identifiers that ICANN coordinates.

The SSR Review Team shall also assess the extent to which ICANN has successfully implemented its security efforts, the effectiveness of the security efforts to deal with actual and potential challenges and threats to the security and stability of the DNS, and the extent to which the security efforts are sufficiently robust to meet future challenges and threats to the security, stability, and resiliency of the DNS, consistent with ICANN’s Mission.

The SSR Review Team shall also assess the extent to which prior SSR Review recommendations have been implemented and the extent to which implementation of such recommendations has resulted in the intended effect.

The SSR Review shall be conducted no less frequently than every five years, measured from the date the previous SSR Review Team was convened (see Bylaws, Section 4.6(c)).

Review Progress and Milestones

​Watch a brief video by ICANN's CTO, as he discusses the 2nd Security, Stability, and Resiliency of the DNS Review Team.

The graphic below illustrates phases and status of each review - a  indicates that all activities within a given phase have been completed.  The chart that follows the graphic provides further details of key activities and milestones within each phase – you can view these details by clicking on each of the phases in the graphic.  The table also contains links to relevant documents.

SSR2
PhaseActivityDescriptionStart DateDocuments
Assemble Review TeamCall for VolunteersPublic announcement inviting volunteers to submit application30 Jun 2016
Call for Volunteers ExtensionApplication Extended for the Second Security, Stability and Resiliency (SSR-2) Review Team12 Aug 2016
Review Team AnnouncedSelection of the Second Security, Stability, and Resiliency of the DNS Review Team Members Announced14 Feb 2017
Appointment of Board DesigneeBoard appoints a member to the Second SSR Review Team3 Feb 2017
Plan ReviewVariousReview team activities and detailed information available on the community wiki30 Jun 2016
Conduct ReviewSecond Security, Stability, and Resiliency of the DNS Review (SSR2) RestartsThe Second Review of the Security, Stability, and Resiliency of the Domain Name System (SSR2) formally restarted 07 June 2018. 7 Jun 2018
Additional FundingBoard resolution approving additional funding7 Nov 2019
Draft ReportDraft Report for Public Comment24 Jan 2020
Public Comment on Draft ReportPublic comment on Second Security, Stability and Resiliency (SSR2) Review Team Draft Report24 Jan 2020
Public Comment ExtendedPublic Comment Period Extended: SSR2 Review Team Draft Report3 Mar 2020
Final Report Executive SummaryExecutive summary of the SSR2 Final Report22 Jan 2021
Final ReportSecond Security, Stability, and Resiliency (SSR2) Review Team Final Report25 Jan 2021
Board ActionPublic Comment on Final ReportFinal report and recommendations posted for Public Comment28 Jan 2021
Board Receipt of the Final ReportBoard receipt of the Final Report3 Mar 2021
Board Action on RecommendationsBoard resolution taking action on 63 recommendations22 Jul 2021
Rationale Supporting Board ResolutionRationale supporting Board resolution22 Jul 2021
ScorecardScorecard: Final SSR2 Review Team Recommendations22 Jul 2021
Board BlogBoard Action and Next Steps on the SSR2 Review26 Jul 2021
Board Action on RecommendationsBoard resolution taking action on three pending recommendations1 May 2022
Rationale Supporting Board ResolutionRationale supporting Board resolution1 May 2022
ScorecardScorecard: SSR2 Pending Recommendations1 May 2022
Operating ProceduresDeferral of Third SSR ReviewDeferral of the Third Review of Security, Stability and Resiliency of the Domain Name System10 May 2022

Implementation of SSR2 Recommendations

On 22 July 2021, the Board took action on the 63 SSR2 recommendations as issued in the SSR2 Review Team Final Report. As noted in its resolution and specified in the Scorecard titled "Final SSR2 Review Team Recommendations – Board Action” the Board resolved to:

  • Approve 13 recommendations subject to prioritization, risk assessment and mitigation, costing, and implementation considerations, as noted below.
  • Reject 16 recommendations (2.1, 2.2, 2.3, 2.4, 4.2, 8.1, 9.4, 10.2, 10.3, 14.1, 14.3, 14.4, 14.5, 15.1, 15.2, 17.2);
  • Place 34 recommendations (3.1, 3.2, 3.3, 4.3, 5.3, 5.4, 6.1, 6.2, 7.1, 7.2, 7.3, 7.4, 7.5, 9.2, 9.3, 11.1, 12.1, 12.2, 12.3, 12.4, 13.1, 13.2, 14.2, 16.2, 16.3, 17.1, 18.1, 18.2, 18.3, 19.1, 19.2, 20.1, 20.2, 24.1) into pending status.

On 1 May 2022 the Board took action on three recommendations that were formerly in pending status. The Board resolved to approve Recommendation 5.4, and reject Recommendations 19.1 and 19.2 issued within the SSR2 Review Team Final Report, as specified within the "Scorecard: SSR2 Pending Recommendations-Board Action 1 May 2022".

ICANN org is working on the remaining pending recommendations in groups: 1) pending/likely to be approved, 2) pending/likely to be rejected, and 3) pending, holding to seek clarity or further information.

ICANN org has initiated the Q&A phase on group 2 recommendations, pending/likely to be rejected, with the SSR2 Implementation Shepherds, while continuing to work on other pending category recommendations in parallel. 

The table below provides information relating to the implementation of Board approved recommendations, including the priority level assigned to each recommendation as a result of the pilot prioritization exercise (more information on this process can be found here).

Implementation status of recommendations should be understood as follows:

  • Complete: a recommendation implemented in full and for which implementation documentation is available.
  • In progress: a recommendation for which work has started to address deliverables identified during the implementation design. Implementation design is the preparatory phase for implementation during which a cross-functional project team develops guidelines that include deliverables for implementation, costing out resources, risk assessment, as well as an inventory of existing work etc.
  • Not started: Work has not started because of a dependency on another recommendation and/or process.

Rec #

Implementation Status

Priority level assigned by the community (where P1 corresponds to the highest priority and P4 to the lowest - See Pilot Prioritization here)

Description

Implementation Update as of 28 June 2022

1.1

In progress

P4

The ICANN Board and ICANN org should perform a further comprehensive review of the SSR1 recommendations and execute a new plan to complete the implementation of the SSR1 Recommendations (see Appendix D: Findings Related to SSR1 Recommendations)

N/A

4.1

Complete

N/A

ICANN org should continue centralizing its risk management and clearly articulate its Security Risk Management Framework and ensure that it aligns strategically with the organization's requirements and objectives. ICANN org should describe relevant measures of success and how to assess them.

ICANN org already has policies, plans and programs in place through which Recommendation 4.1 has already been implemented, and the Board continues its oversight role over ICANN org's risk management efforts. The Board is supportive of ICANN org in continuing the risk management activities that it is already carrying out. Implementation documentation is in progress.

5.1

Not started

Not eligible for prioritization

ICANN org should implement an ISMS and be audited and certified by a third party along the lines of industry security standards (e.g., ITIL, ISO 27000 family, SSAE-18) for its operational responsibilities. The plan should include a road map and milestone dates for obtaining certifications and noting areas that will be the target of continuous improvement.

There is a dependency on the migration to the U.S. Department of Commerce National Institute of Standards and Technology (NIST) Cybersecurity Framework.

5.2

Not started

Not eligible for prioritization

Based on the ISMS, ICANN org should put together a plan for certifications and training requirements for roles in the organization, track completion rates, provide rationale for their choices, and document how the certifications fit into ICANN org's security and risk management strategies.

There is a dependency on the migration to the U.S. Department of Commerce National Institute of Standards and Technology (NIST) Cybersecurity Framework.

5.4

Not started

N/A

ICANN org should reach out to the community and beyond with clear reports demonstrating what ICANN org is doing and achieving in the security space. These reports would be most beneficial if they provided information describing how ICANN org follows best practices and mature, continually-improving processes to manage risk, security, and vulnerabilities.

N/A

9.1

Complete

N/A

The ICANN Board should direct the compliance team to monitor and strictly enforce the compliance of contracted parties to current and future SSR and abuse related obligations in contracts, baseline agreements, temporary specifications, and community policies.

The Contractual Compliance operations that ICANN org has in place already met the SSR2 Review Team's defined measures of success for Recommendation 9.1. Implementation documentation is in progress.

10.1

Not started

P1

ICANN org should post a web page that includes their working definition of DNS abuse, i.e., what it uses for projects, documents, and contracts. The definition should explicitly note what types of security threats ICANN org currently considers within its remit to address through contractual and compliance mechanisms, as well as those ICANN org understands to be outside its remit. If ICANN org uses other similar terminology—e.g., security threat, malicious conduct—ICANN org should include both its working definition of those terms and precisely how ICANN org is distinguishing those terms from DNS abuse. This page should include links to excerpts of all current abuse-related obligations in contracts with contracted parties, including any procedures and protocols for responding to abuse. ICANN org should update this page annually, date the latest version, and link to older versions with associated dates of publication.

N/A

16.1

Not started

P3

ICANN org should provide consistent cross-references across their website to provide cohesive and easy-to-find information on all actions—past, present, and planned—taken on the topic of privacy and data stewardship, with particular attention to the information around the RDS.

N/A

21.1

Not started

P1

ICANN org and PTI operations should accelerate the implementation of new RZMS security measures regarding the authentication and authorization of requested changes and offer TLD operators the opportunity to take advantage of those security measures, particularly MFA and encrypted email.

N/A

22.1

Not started

P4

For each service that ICANN org has authoritative purview over, including root-zone and gTLD-related services as well as IANA registries, ICANN org should create a list of statistics and metrics that reflect the operational status (such as availability and responsiveness) of that service, and publish a directory of these services, data sets, and metrics on a single page on the icann.org web site, such as under the Open Data Platform. ICANN org should produce measurements for each of these services as summaries over both the previous year and longitudinally (to illustrate baseline behavior).

N/A

22.2

Not started

P4

ICANN org should request community feedback annually on the measurements. That feedback should be considered, publicly summarized after each report, and incorporated into follow-on reports. The data and associated methodologies used to measure these reports' results should be archived and made publicly available to foster reproducibility.

N/A

23.1

Not started

P3

PTI operations should update the DNSSEC Practice Statement (DPS) to allow the transition from one digital signature algorithm to another, including an anticipated transition from the RSA digital signature algorithm to other algorithms or to future post-quantum algorithms, which provide the same or greater security and preserve or improve the resilience of the DNS.

N/A

23.2

Not started

P1

As a root DNSKEY algorithm rollover is a very complex and sensitive process, PTI operations should work with other root zone partners and the global community to develop a consensus plan for future root DNSKEY algorithm rollovers, taking into consideration the lessons learned from the first root KSK rollover in 2018.

N/A

24.2

Not started

P4

ICANN org should make the Common Transition Process Manual easier to find by providing links on the EBERO website.

N/A

For information on the first SSR Review, click here: SSR1

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."