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







n/a

Hide the information below, please click here 

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