Developing a process for the potential implementation of proposals from the Domain Name System Security Facilitation Initiative Technical Study Group (DSFI-TSG) is one of ICANN President and Chief Executive Officer Göran Marby’s goals for Fiscal Year 2022. This page includes information related to the status of this work.
|Rec #||Description||Statement of Understanding|
|Category: Operational Improvement|
O1: Develop a Tabletop Exercise Program
|Recommendation text: ICANN org, together with the SSAC, GNSO, ccNSO, and other entities with relevant expertise as the org is able to identify them, should develop a tabletop exercise program (e.g., a technical study group, a task-specific technical operators’ group) to exercise incident-response procedures and identify operational gaps for services provided by registries and registrars. ICANN org should facilitate the closing of operational gaps identified as it is able by working with the relevant parties.|
ICANN org understands this recommendation is asking that ICANN org first collaborate “with the SSAC, GNSO, ccNSO, and other entities with relevant expertise as the org is able to identify them” to develop a tabletop exercise program “to exercise incident-response procedures and identify operational gaps for services provided by registries and registrars.”
To ensure its success, the program needs to include all relevant parties with expertise, and as such, there are several questions that will need to be answered during implementation planning, such as:
Furthermore, as entities in the group developing the tabletop exercise program will be sharing incident response procedures, this group needs to be a trusted group, with the promise of and protection to the confidentiality of deliberations and any materials shared.
ICANN org will collaborate with appropriate entities to determine what form the tabletop exercise program can be in, for example “a technical study group or a task-specific operators group”, or if there are existing mechanisms that may be used. Once the gaps are identified by the tabletop exercise, ICANN org will “facilitate the closing of the gaps by working with relevant parties.”
R1: Continue Existing Work on DNS Abuse
Recommendation text: ICANN org should continue to participate in industry efforts to develop the definitions and actions regarding DNS abuse, and support the security and research community in identifying and mitigating DNS abuse via research funding for those identified experts.
Additional notes included in the report: DNS abuse takes many forms. Being able to clearly define what serves as abuse is an important step in determining how to mitigate that abuse.
ICANN org understands this recommendation is asking for ICANN to continue its efforts in engaging with and participating in industry efforts to develop definitions and actions that can be taken to mitigate DNS Abuse. Additionally, this recommendation encourages ICANN to fund further research related to identifying and mitigating DNS Abuse. Finally, this recommendation encourages the development of methods to clearly define something as abuse.
R2: Investigate DNS Security Enhancements
Recommendation text: ICANN org should develop a program to continually investigate the limits, risks, and benefits of various DNS security enhancements such as, but not limited to:
The recommendation is clear as written. ICANN org does not require further clarification.
R3: Investigate Appropriate Best Practice for Authentication (DSFI-TSG priority)
Recommendation text: ICANN org, along with relevant organizations and communities, should conduct a study and offer a report on what should be considered best practice for authentication when considered against the different roles and risks in the DNS.
Additional notes included in the report: The DSFI-TSG recognizes that there are many sources for “best practice” around authentication when it comes to the actors that play a role in the DNS ecosystem, such as registries, registrars, resellers, DNS providers, and registrants.
ICANN org understands "authentication" in this context as the means by which parties are granted access to any change process within the DNS service infrastructure. This recommendation requires ICANN org to work with the community to conduct a study, and use the results to develop a framework that:
C1: Empower Contracted Parties
|Recommendation text: ICANN org should work to empower contracted parties to adopt security enhancements to the domain registration systems and authoritative name services as practical.|
ICANN org understands that this recommendation is asking ICANN org to make it easier for contracted parties to adopt technologies and procedures that enhance the security of the domain name registration system.
F1: Bug Bounty Program Feasibility Funding
Recommendation text: ICANN org should lead an effort to work with DNS software, hardware, and service vendors, as well as registry and registrar software vendors, to investigate the feasibility of funding and/or supporting the creation of DNS-related bug bounty programs. ICANN org should review the findings of that investigation and make recommendations for any further efforts. ICANN org should include in its reports information on the feasibility of bug bounty programs and what mechanisms are available for reporting vulnerabilities. As a final step, use the results of these reports to create a central list of all DNS bug bounty programs and reporting mechanisms that will be maintained regularly.
Additional notes included in the report: A bug bounty program may result in DNS protocol or implementation vulnerabilities being discovered and disclosed responsibly. Part of this program may include an interoperability testbed to enable cross-platform verification testing of newly discovered or reported vulnerabilities. In all cases, a bug bounty program would need continual attention and strong cross-functional collaboration.
ICANN org understands that the primary body of work this recommendation is asking for is for ICANN org to act as a facilitator to drive and fund the engagement with DNS software/hardware/service vendors as well as registry/registrars to act as a trusted party and support relationship building between parties [reporters and fixers] that are part of a responsible disclosure process whenever possible/needed.
|Category: Education & Awareness|
E1: Education around Authentication
Recommendation text: ICANN org should build educational programs encouraging DNS stakeholders to make available the appropriate standards-based authentication mechanisms for all interactions that should be authenticated, as well as informing those stakeholders of the risks associated with weak authentication schemes. ICANN org should also support these programs through communication tactics.
Additional notes included in the report: At the time of publication, the DSFI-TSG believes that a training program such as this should include discussion and encouragement of multi-factor authentication and less reliance on solely password-based authentication. The ICANN community and industry experts could help in drafting such best practices based on their expertise. ICANN org could play a central role in the process of promoting and modeling their use in ICANN infrastructure, policies, and contracts. The DSFI-TSG recognizes that this recommendation overlaps recommendations offered in SAC074 and offers a strong opportunity for ICANN org to partner with other organizations to extend the education and awareness efforts.
ICANN org understands this recommendation is asking ICANN org to develop capacity building materials to raise awareness among DNS operator stakeholders (including technical teams at registries and registrars) on the importance of credential management for each authentication point within their service infrastructure. This recommendation mirrors SAC074 advice which is currently in its implementation phase. Achieving this will require preliminary work to identify and classify credential management best practices both from service providers and client perspectives.
E2: Registry Lock
Recommendation text: ICANN org should undertake efforts to improve documentation and understanding of Registry Lock features and to promote their uses, when appropriate, and improve the understanding regarding the differences between Registry and Registrar Lock. Registrants should be able to find clear definitions of what these features provide, what these features do not provide, and the difference between them. ICANN org should consider facilitating the standardization of minimum requirements for Registry and Registrar Lock services.
Additional notes included in the report: ICANN org could do this by working with the technical community and/or by providing funds for research that explores the benefit of such a process as well as facilitating discussions around it. This may build on existing work, such as the Council of European National Top-Level Domain Registries’ white paper, “Models of registry lock for top-level domain registries.”
ICANN org understands this recommendation is asking ICANN org to:
E3: Awareness of Best Practices for Infrastructure Security
|Recommendation text: ICANN org should continue to participate in initiatives such as MANRS and KINDNS to measure and report on their adoption, and use those reports to create targeted educational material to improve awareness about infrastructure security. ICANN org should take the best practices coming out of those initiatives and ensure that contracted parties and the ICANN community are aware of them. Where current best practices do not exist, ICANN org should work to encourage the development and deployment of said practices and promote the adoption of DNS security-enhancing features throughout the DNS ecosystem (e.g., DMARC, SPF, TLSA, DANE, DNSSEC, etc.).|
ICANN org understands this recommendation to have several components that are linked to each other. First, ICANN org should actively support initiatives such as Mutually Agreed Norms for Routing Security (MANRS) and KINDNS that promote routing and DNS operational best practices. Second, ICANN org should develop a mechanism to measure their adoption and adjust targeted information campaigns accordingly. Finally, within ICANN technical mission's remit, ICANN org should work with the operator community to develop, document, and promote relevant best practices that are not yet well articulated.
E4: DNS Blocking and Filtering
Recommendation text: ICANN org should create informative and educational materials to help the ICANN community, contracted parties, and other interested parties understand the risks and benefits of DNS blocking and filtering for security and stability reasons throughout the global DNS infrastructure community.
Additional notes included in the report: Understandings should include best practices, tooling for understanding DNS interdependencies to avoid large-scale collateral damage, use of the Public Suffix List (PSL), allow lists and similar lists to avoid overblocking, and general hygiene for these types of activities.
ICANN org understands this recommendation is asking ICANN org to develop a dedicated education program for the DNS operator community around better understanding the impact (positive or negative) of various DNS filtering and blocking techniques. This will require a preliminary research project to identify and map out different filtering and blocking techniques to the components of general DNS operation processes and their impacts.
E5: Incident Response (DSFI-TSG priority)
Recommendation text: ICANN org should, together with relevant parties, encourage the development and deployment of a formalized incident-response process across the DNS industry that allows for interaction with others in the ecosystem. Such an effort should include incident-response handling as well as the protected sharing of threat and incident information.
Additional notes included in the report: This effort could be based on incident-response best practices from other industries and could be based in part on prior work and recommendations from SSAC’s SAC115 and the Security, Stability, and Resiliency Review Team’s (SSR2) recommendation 6, “SSR Vulnerability Disclosure and Transparency.”
ICANN org understands this recommendation is asking ICANN org to encourage (perhaps some other party) to develop a DNS incident response capability that will provide a centralized process for the sharing of relevant cyber threat intelligence for the detection, containment, and mitigation of relevant DNS-related security incidents. Such incident response capabilities will be based on standards, norms, and procedures recognized by the incident response communities and would allow for facilitation and engagement towards addressing relevant malicious infrastructure.
The recommendation encourages ICANN org to support a standardized response framework, not to have ICANN develop its own response function directly.
E6: Covert Channel Awareness
|Recommendation text: ICANN org should publish educational material on the use of covert channels as an attack vector, which may be seen as an abuse of the DNS itself and as such, requires handling as with other DNS abuse issues. Additional notes included in the report: This may become increasingly important with the wider adoption of DNS encryption protocols and services.|
ICANN org understands this recommendation is asking for ICANN org to develop detailed communication and educational materials explaining how covert channels used as attack vectors leverage the DNS.