DNS Security Facilitation - Technical Study Group: Difference between revisions

(19 intermediate revisions by 2 users not shown)

Line 1:

The '''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.

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.<ref>[https://community.icann.org/display/DSFI/Project+Charter+and+Scope?preview=/136119336/146736288/DSFI%20Technical%20Study%20Group%20Charter.pdf DSFTSG Charter]</ref> 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?<ref>[https://community.icann.org/display/DSFI/Project+Charter+and+Scope?preview=/136119336/146736288/DSFI%20Technical%20Study%20Group%20Charter.pdf DSFTSG Charter]</ref>

# 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]].<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==

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 [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 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 [[CPH|Contracted Parties]] to adopt security enhancements to the domain registration systems and authoritative name services

# 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

# 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]]

# 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 [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.

==References==

[[Category:DNS Abuse Responses]]

[[Category:Cybersecurity]]

@@ Line 1: / Line 1: @@
-The '''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.
+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.<ref>[https://community.icann.org/display/DSFI/Project+Charter+and+Scope?preview=/136119336/146736288/DSFI%20Technical%20Study%20Group%20Charter.pdf DSFTSG Charter]</ref> 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?<ref>[https://community.icann.org/display/DSFI/Project+Charter+and+Scope?preview=/136119336/146736288/DSFI%20Technical%20Study%20Group%20Charter.pdf DSFTSG Charter]</ref>
+# 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]].<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==
+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 [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 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 [[CPH|Contracted Parties]] to adopt security enhancements to the domain registration systems and authoritative name services
+# 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
+# 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]]
+# 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 [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.
+==References==
+[[Category:DNS Abuse Responses]]
+[[Category:Cybersecurity]]