DNS Security Facilitation - Technical Study Group: Difference between revisions
| (5 intermediate revisions by the same user not shown) | |||
| Line 27: | Line 27: | ||
==History== | ==History== | ||
The group met 29 times between June 2020 and September 2021 to answer the aforementioned questions and draft recommendations for the [[ICANN CEO]].<ref>[https://community.icann.org/display/DSFI/Work+Plan+and+Timeline?preview=/136120022/160727866/DSFI%20Milestones%20Timeline.pdf DSFTSG Key Meetings Timeline]</ref> The group submitted its draft report to the ICANN CEO in October 2021, just prior to ICANN 72.<ref>[https://www.icann.org/en/blogs/details/dns-security-facilitation-technical-study-group-delivers-final-report-13-10-2021-en ICANN.org Blog - DSFI-TSG Delivers its Final Report], October 13, 2021</ref> At [[ICANN 72]], the group presented its findings in a session during Prep Week.<ref>[https://72.schedule.icann.org/meetings/4FLR7CFvzr2JrnL3p ICANN 72 Archive - Introducing the DSFI-TSG], October 14, 2021</ref> | The group met 29 times between June 2020 and September 2021 to answer the aforementioned questions and draft recommendations for the [[ICANN CEO]].<ref>[https://community.icann.org/display/DSFI/Work+Plan+and+Timeline?preview=/136120022/160727866/DSFI%20Milestones%20Timeline.pdf DSFTSG Key Meetings Timeline]</ref> The group submitted its draft report to the ICANN CEO in October 2021, just prior to ICANN 72.<ref>[https://www.icann.org/en/blogs/details/dns-security-facilitation-technical-study-group-delivers-final-report-13-10-2021-en ICANN.org Blog - DSFI-TSG Delivers its Final Report], October 13, 2021</ref> At [[ICANN 72]], the group presented its findings in a session during Prep Week.<ref>[https://72.schedule.icann.org/meetings/4FLR7CFvzr2JrnL3p ICANN 72 Archive - Introducing the DSFI-TSG], October 14, 2021</ref><br/> | ||
In April 2022, the Office of the Chief Technology Officer ([[OCTO]]) announced its plan to process the DSFI-TSG proposals. Although the DSFI-TSG recommendations were beyond the scope of the [[AC|Action Request Register]], which is for [[ICANN Board]] advice, the OCTO is using the ARR framework for the DSFI_TSG recommendations. The four phases of this process are: understand, evaluate, consult the [[ICANN Community]], and implementation.<ref>[https://www.icann.org/en/blogs/details/icann-is-developing-a-process-for-evaluating-dsfi-tsg-recommendations-20-04-2022-en DSFI-TSG Recommendation Implementation Process]</ref> | |||
==Work Product== | ==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 Compliance|contractual controls]] and offered 12 recommendations:<ref>[https://community.icann.org/display/DSFI/DSFI+TSG+Final+Report?preview=/176623416/176623417/DSFI-TSG-Final-Report.pdf DSFI-TSG Final Report, ICANN Community]</ref> | 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 Compliance|contractual controls]] and offered 12 recommendations:<ref>[https://community.icann.org/display/DSFI/DSFI+TSG+Final+Report?preview=/176623416/176623417/DSFI-TSG-Final-Report.pdf DSFI-TSG Final Report, ICANN Community]</ref> | ||
# Develop a Tabletop Exercise Program | # Develop a [https://www.redlegg.com/solutions/advisory-services/tabletop-exercise-pretty-much-everything-you-need-to-know Tabletop Exercise] Program to exercise incident-response procedures and identify operational gaps for services provided by registries and registrars and facilitate closing them | ||
# Continue | # 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 DNS Security Enhancements | ||
# Investigate Best Practices for Authentication | # Investigate Best Practices for Authentication | ||
# Empower [[CPH|Contracted Parties]] to adopt security enhancements to the domain registration systems and authoritative name services | # Empower [[CPH|Contracted Parties]] to adopt security enhancements to the domain registration systems and authoritative name services | ||
# Bug Bounty Program Feasibility Funding | # Offer [https://www.bugcrowd.com/bug-bounty-list/ Bug Bounty Program] Feasibility Funding | ||
# Educate DNS stakeholders to make available the appropriate standards-based authentication mechanisms for all interactions | # 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 | # Improve documentation and understanding of [[Domain Locking|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 [[ICANN Terms#Infrastructure|Infrastructure]] Security by participating in initiatives such as [[MANRS]] and [[KINDNS]] and promoting the adoption of [[DMARC]], [[SPF]], [[TLSA]], [[DANE]], and [[DNSSEC]] | # Raise Awareness of Best Practices for [[ICANN Terms#Infrastructure|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 [[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 | ||
# 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. | ||
Latest revision as of 17:55, 20 April 2022
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]
In April 2022, the Office of the Chief Technology Officer (OCTO) announced its plan to process the DSFI-TSG proposals. Although the DSFI-TSG recommendations were beyond the scope of the Action Request Register, which is for ICANN Board advice, the OCTO is using the ARR framework for the DSFI_TSG recommendations. The four phases of this process are: understand, evaluate, consult the ICANN Community, and implementation.[6]
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:[7]
- 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.