DNS Security Facilitation - Technical Study Group: Difference between revisions
| Line 42: | Line 42: | ||
# Help the [[ICANN Community]], contracted parties, and others understand the risks and benefits of DNS [[RBL|Blocking]] and filtering for [[SSR|security and stability reasons]], best practices, tooling for DNS interdependencies to avoid large-scale collateral damage, using the Public Suffix List ([[PSL]]), sharing lists to avoid overblocking, and general reputation hygiene | # Help the [[ICANN Community]], contracted parties, and others understand the risks and benefits of DNS [[RBL|Blocking]] and filtering for [[SSR|security and stability reasons]], best practices, tooling for DNS interdependencies to avoid large-scale collateral damage, using the Public Suffix List ([[PSL]]), sharing lists to avoid overblocking, and general reputation hygiene | ||
# Develop and deploy a formalized incident-response process across the DNS industry that allows for interaction with others in the ecosystem | # Develop and deploy a formalized incident-response process across the DNS industry that allows for interaction with others in the ecosystem | ||
# Raise Covert Channel Awareness | # Raise [https://ieeexplore.ieee.org/document/9248526 Covert Channel] Awareness | ||
Of these recommendations, the TSG said the two top priorities for ICANN were conducting a study and offering a report on best practices for authentication against the different roles and risks in the DNS and encouraging the development and deployment of a formalized incident-response process across the DNS industry that allows for interaction with others in the ecosystem. | Of these recommendations, the TSG said the two top priorities for ICANN were conducting a study and offering a report on best practices for authentication against the different roles and risks in the DNS and encouraging the development and deployment of a formalized incident-response process across the DNS industry that allows for interaction with others in the ecosystem. | ||
Revision as of 20:34, 18 November 2021
The DNS Security Facilitation - Technical Study Group (DSFI-TSG) was formed to investigate and determine what ICANN should and should not do based on the technical landscape -- not about DNS Abuse -- but about security threats and attack vectors, including the DNS itself. This study group provides technical guidance to the ICANN CEO on what ICANN can initiate to facilitate DNS security.[1] This group does not make policy but it may make policy recommendations.
Members
- Merike Käo (Coordinator)
- Tim April
- Gavin Brown
- John Crain
- Rod Rasmussen
- Marc Rogers
- Katrina Sataki
- Robert Schischka
- Duane Wessels
Guiding Questions
- Which ICANN mechanisms or functions specifically address DNS security?[2]
- What are the most critical gaps in the DNS security landscape?
- what technical requirements are needed to fill the gaps?
- How to fix operational best practices to address the gaps?
- What are the hindrances to their deployments?
- Who should fill those gaps?
- what is ICANN Organization's role?
- What strategic partnerships should ICANN org make to enhance DNS security?
- What are the risks?
- What are the shortcomings of the current threat models?
- What are the externalities?
- which DNS characteristics attract security problems that other Internet services don’t have?
- What can ICANN learn from other protocols or industries that face similar issues?
History
The group met 29 times between June 2020 and September 2021 to answer the aforementioned questions and draft recommendations for the ICANN CEO.[3] The group submitted its draft report to the ICANN CEO in October 2021, just prior to ICANN 72.[4] At ICANN 72, the group presented its findings in a session during Prep Week.[5]
Work Product
The Final Report indicated that ICANN Organization can improve the security of the DNS directly, through funded research and education, and indirectly through partnerships, community collaboration, and contractual controls and offered 12 recommendations:[6]
- Develop a Tabletop Exercise Program to exercise incident-response procedures and identify operational gaps for services provided by registries and registrars and facilitate closing them
- Continue developing the definitions of DNS Abuse and support the security and research communities in identifying and mitigating DNS abuse via SME research funding
- Investigate DNS Security Enhancements
- Investigate Best Practices for Authentication
- Empower Contracted Parties to adopt security enhancements to the domain registration systems and authoritative name services
- Offer Bug Bounty Program Feasibility Funding
- Educate DNS stakeholders to make available the appropriate standards-based authentication mechanisms for all interactions
- Improve documentation and understanding of Registry Lock features and promote their use; explain the differences between Registry and Registrar Lock to registrants; facilitate the standardization of minimum requirements for Registry and Registrar Lock services
- Raise Awareness of Best Practices for Infrastructure Security by participating in initiatives such as MANRS and KINDNS and promoting the adoption of DMARC, SPF, TLSA, DANE, and DNSSEC
- Help the ICANN Community, contracted parties, and others understand the risks and benefits of DNS Blocking and filtering for security and stability reasons, best practices, tooling for DNS interdependencies to avoid large-scale collateral damage, using the Public Suffix List (PSL), sharing lists to avoid overblocking, and general reputation hygiene
- Develop and deploy a formalized incident-response process across the DNS industry that allows for interaction with others in the ecosystem
- Raise Covert Channel Awareness
Of these recommendations, the TSG said the two top priorities for ICANN were conducting a study and offering a report on best practices for authentication against the different roles and risks in the DNS and encouraging the development and deployment of a formalized incident-response process across the DNS industry that allows for interaction with others in the ecosystem.