AT-LARGE GATEWAY

At-Large Website

ALAC

RALOs

At-Large Regional Policy Engagement Program (ARPEP)

At-Large Governance

At-Large Reports

Policy Comments & Advice

Working Groups

ICANN Meetings

At-Large Summit (ATLAS III)

At-Large Review Implementation Plan Development

ALAC and RALO Elections, Selections, and Appointments

At-Large Priority Activities - 2021

Public Comment CloseStatement
Name 

Status

Assignee(s)

Call for
Comments Open		Call for
Comments
Close 		Vote OpenVote CloseDate of SubmissionStaff Contact and EmailStatement Number


31 July 2017


Draft Framework for the Registry Operator to Respond to Security Threats


No Statement


n/a







Dennis Chang
dennis.chang@icann.org


n/a

Hide the information below, please click here 


Brief Overview

Purpose: This public comment forum is intended to gather community feedback on the proposed Framework for the Registry Operator to Respond to Security Threats that has been a collaborative effort of the members of the Security Framework Drafting Team (SFDT) on behalf of the Registries Stakeholder Group (RySG), Public Safety Working Group (PSWG), Registrar Stakeholder Group (RrSG) and ICANN organization.

Current Status: The SFDT, consisting of representatives from registries, registrars, and the GACPSWG, has collaborated with ICANN organization over the past two years to produce this draft document (“Framework”). The draft document has been reviewed by the RySG, RrSG, PSWG of the Governmental Advisory Committee (GAC), and those organizations did not object to or express concern with the draft.

Next Steps: ICANN organization will prepare a public comment summary report at the conclusion of the comment period. SFDT will consider in-scope comments and after finalizing the Framework document, it will be publicly posted on the ICANN website for the benefit of the community.

Section I: Description and Explanation

The objective of the Framework is to deliver on the New gTLD Program Committee of the ICANNBoard’s (NGPC) commitment to the GAC regarding ICANN soliciting community participation to develop a framework for how a Registry Operator (RO) may respond to identified security threats. This framework is a voluntary and non-binding document designed to articulate guidance as to the ways ROs may respond to identified security threats.

The Framework sets out some of the security issues law enforcement face and outlines the most common options available to ROs to address identified security threats. It is designed to assist both law enforcement and ROs in understanding the issues and limitations faced and to provide resources and alternatives for resolving identified security threats.

This Framework does not address situations where an RO does not have discretion to respond (such as subject to a Court Order from a court of competent jurisdiction over the RO) or situations where the RO’s policies would prohibit it from taking any particular action. The Framework (and the practices contained therein) does not reflect any consensus policy affecting ROs.

Section II: Background

While developing the terms of the Registry Agreements in the New gTLD Program, the NGPC resolved to include the so called “security checks” into Specification 11 section 3b (see the New gTLD Registry Agreement). While doing so, the NGPC recognized that these terms were general guidelines which omitted specific details because there are multiple ways for ROs to respond to identified security risks. In order to allow for careful and fulsome consideration of these implementation details, the NGPC Proposal for Implementation of GAC Safeguards Applicable to All New gTLDs called for ICANN to solicit community participation to develop a framework for “Registry Operators to respond to identified security risks that pose an actual risk of harm (…)”.

After conducting a preliminary consultation with a group of ROs and GAC representatives, ICANN formed a Framework Drafting Team composed of volunteers from affected parties to draft a Framework for Registry Operators to Respond to Security Threats. ROs, registrars, and GAC representatives (including from the Public Safety Working Group) participated in the drafting effort.

Section III: Relevant Resources


  1. The Framework Draft: https://community.icann.org/download/attachments/54693403/Security%20Framework%20draft%20v8.pdf?version=1&modificationDate=1496856148416&api=v2
  2. Security Framework Drafting Team wiki workspace: https://community.icann.org/display/S1SF/Security+Framework+Home
  3. NGPC Direction to ICANN Org: https://www.icann.org/resources/board-material/resolutions-new-gtld-2013-06-25-en#2.b
  4. GAC Advice: https://www.icann.org/en/system/files/correspondence/gac-to-board-18apr13-en.pdf


Section IV: Additional Information

Section V: Reports

Staff Contact

Dennis Chang
dennis.chang@icann.org

FINAL VERSION TO BE SUBMITTED IF RATIFIED

The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote. 


 

FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC

The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.


 

FIRST DRAFT SUBMITTED

The first draft submitted will be placed here before the call for comments begins.


1 Comment

  1. Olivier Crepin-Leblond

    After the last ALAC call where I took on the responsibility to check on whether the ALAC needed to respond, several people have contacted me pointing comments that we might be interested in making:

    • use of "must" or "may" vs. "can" - whereas in a sentence where the Registry Operator can acknowledge

    "If and when requests are categorized as “High Priority” and of a legitimate and credible origin, then as soon as possible and no later than 24 hours of acknowledging receipt, the Registry Operator can acknowledge the threat and communicate its planned steps to mitigate the security threat."

    Ricardo Holmquist (LACRALO) suggested that the term "may" be used, as "can" signals a permission.

    • Bastiaan Goslings notes that the draft does not define ‘security threats’ nor does it refer to a source that frames the term - and felt that the document might benefit from such definition.
    • Bastiaan also makes the following comments:
      • On page 4 'A) Reports from Law Enforcement Authorities' 

‘this framework encourages ROs to consider such reports to be of a higher fidelity, and as such are afforded with all due priority. While ROs should proceed with a higher degree of certainty with respect to referrals from LEAs, they should still conduct any investigation they deem necessary to ensure that the referrals properly constitute a security threat and to confirm the validity of the referral source.’

(Is this comparable to a ‘notice and take down’ request? If so I think there should be a link to ‘High Priority’ on page 5: ‘“High Priority” should be considered an imminent threat to human life, critical infrastructure or child exploitation.’ And importantly, ‘any other incident not categorized as “High Priority”, related to technical abuse of the DNS, will be handled according to the Anti-Abuse policy of the registry when they have the appropriate legal discretion.’ So when no ‘legal discretion’, no ‘action')

I struggle with the ‘higher fidelity, and as such are afforded with all due priority’, just because a ‘report’ is from a LEA, combined with the ‘ensure that the referrals properly constitute a security threat and to confirm the validity of the referral source.’

‘Confirm the validity’ is IMO not the same as determining that a (request in a) report from a LEA is actually legitimate (—> compare with court order). And that this ‘ensuring’ means that e.g. ‘holding’, ‘locking’, ’redirecting’ or ‘deleting’ a domain name on request of a LEA is indeed an appropriate form of ’action’. 

Good point btw on page 6: ‘It is encouraged that ROs communicate the analysis of the threat to the requestor in order to clarify why they may or may not be taking further action or that mitigation should be handled through a different party.’
    • Tatiana Tropina emphasized that this was a voluntary framework, thus language could benefit from not being too restrictive thus leaving the room for checks and balances and for additional investigations even if the reports seem credible.


    In the light that this is a voluntary framework and is therefore not prescriptive, the comments above did not appear to warrant an ALAC Statement into the topic.