Public Comment CloseStatement
Name 

Status

Assignee(s)

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

20 March 2020

ADOPTED

13Y, 0N, 0A

26 February 2020

19 March 2020

20 March 2020

24 March 2020

20 March 2020

AL-ALAC-ST-0320-02-01-EN

Hide the information below, please click here 

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



DRAFT SUBMITTED FOR DISCUSSION

The first draft submitted will be placed here before the call for comments begins. The Draft should be preceded by the name of the person submitting the draft and the date/time. If, during the discussion, the draft is revised, the older version(S) should be left in place and the new version along with a header line identifying the drafter and date/time should be placed above the older version(s), separated by a Horizontal Rule (available + Insert More Content control).

Draft submitted by Alan Greenberg and Jonathan Zuck, 25 February 2020, 16:20 UTC

Minor correction (confirming reference to CCT Review) and correcting a typo, 26 February 2020.

New text added in response to comments, shown in BLUE, added by Alan Greenberg, 19 March 2020, 20:48 UTC.


The ALAC appreciates the opportunity to comment on the Second Security, Stability, and Resiliency (SSR2) Review Team Draft Report.

Ensuring the security, stability and resiliency of the DNS is arguably ICANN's single most important role.

SSR1 issued 28 recommendations. The ICANN Org reports indicated the Board judged all to be relevant and implementable and that all were fully implemented. The SSR2 analysis was that of the 28 recommendations, 2 were not implemented at all, 26 were partially implemented and none fully implemented. Of these 27 of the 28 were found to still be relevant. That is an astounding analysis 8 years after the acceptance of the SSR1 recommendations.

The ALAC has a particular interest in the recommendations related to domain name abuse, and notes that several of the recommendations overlap with and complement those issued by the RDS-WHOIS2-RT and the CCT RT.

The ALAC also notes that in the opinion of the SSR2 RT, many of the recommendations are deemed to be of high priority. Given the current interest in ICANN of prioritizing activities with the implicit effect of not addressing those lower on the list, this could lead to not addressing issues critical to the SSR of the DNS. DNS Security, stability and resiliency is not something that we can afford to ignore. The lead item in ICANN's Strategic Plan is "Strengthen the security of the Domain Name System and the DNS Root Server System.". This must be taken into account when allocating resources and we trust that this will be taken into account when the Board works with the RT Implementation Shepherds on deciding how to prioritize the recommendation implementation.

The ALAC has a particular focus on and interest in DNS Abuse. To address this may require contractual changes to facilitate Contractual Compliance action. Such changes require either negotiations with the contracted parties or a PDP. A PDP will take considerable time and the ALAC does not advocate such a path, but rather it is time for ICANN Org and specifically Contractual Compliance to meet with those contracted parties who have shown an interest in DNS Abuse mitigation, and come to an agreement on needed contractual changes, factoring in not only penalties but any incentives that can be reasonably provided to encourage compliance.

Given the potential for rejection or deferral of the large number of high priority items, the ALAC encourages the review team to strengthen the justification on the high priority items.

Summary:

We are living in a world where many parties seem to have a interest in destabilizing critical infrastructure and the Internet in particular. The fact that our systems have been sufficiently robust in the past is not an indication that this is sustainable moving forward. ICANN needs to take seriously the need to professionally and rigorously ensure the SSR of its DNS operations. In particular, known vulnerabilities need to be corrected with the utmost haste.

10 Comments

  1. We do not have the time nor expertise to do a detailed analysis of the report. I suggest a short but STRONG statement and propose the following major points.

    ======================

    Ensuring the security, stability and resiliancy of the DNS is arguably ICANN's simgle most important role.

    SSR1 issued 28 recommendations. The ICANN Org reports indicated the Board judged all to be relevant and implementable and that all were fully implemented. The SSR2 analysis was that of the 28 recommendations, 2 were not implemented at all, 26 were partially implemented and none fully implemented. Of these 27 of the 28 were found to still be relevant. That is an astounding analysis 8 years after the acceptance of the SSR1 recommendations.

    The ALAC has a particular interest in the recommendations related to domain name abuse, and notes that several of the recomemendations overlap with and complement those issues by the RDS-WHOIS2-RT [and the CCT RT?].

    The ALAC also notes that in the opinion of the SSR2 RT, many of the recommendations are deemed to be of high priority. Given the current interest in ICANN of prioritizing activities with the implict effect of not addressing those lower on the list, this could lead to not addressing issues critical to the SSR of the DNS.

    General Comment:

    We are living in a world where many parties seem to have a interest in destabilizing critical infrastructure and the Internet in particular. The fact that our systems have been sufficiently robust in the past is not an indication that this is sustainable moving forward. ICANN needs to take seriously the need to professionally and rigourously ensure the SSR of its DNS operations. I particular, known vulnerabilities need to be corrected with the utmost haste.

  2. Great comment. Nothing to add. Thanks Alan and Jonathan

  3. "when the Board works with the RT Implementation Shepherds on deciding how to prioritize"

    Not sure that the Board will be (or is) in charge of prioritization.

    1. Not sure who else will. Implicitly be what they accept there will be SOME prioritization. And I know from the RDS-WHOIS2 Review, they will be discussing what the RT meant by their priorities.


      Staff in their report to the Board will surely imply priorities but it is up to the Board to decide to what extent to follow that.


      All that being said, if you have better wording to propose, please do.


      Alan

  4. I would suggest plugging somewhere that the Security and Stability of the DNS is an ICANN Core Issue.


  5. As a vice chair of this review team, I welcome this comment.

    From my perspective as a member of the team (and ALAC), we identify some key issues that would be worth mentioning, or provide at least some words on:

    • DNS abuse (and not enough anti-abuse) and what the review team considers as insufficient contractual provisions and enforcement when it comes to parties harboring systemic abuse (i.e. high rates of abusive registration, lack of cooperation, etc.) Includes centralizing abuse reporting, whois, etc.
      • The lack of contractual obligations and rules regarding DNS abuse, and compliance not enforcing sufficiently is the key issue the team sees here.
    • Lack of proper security leadership (CSO, CISO - a one stop shop for security) that leads, coordinates, and is responsible for security (e.g. risk management, business continuity, disaster recovery, information security management system).
    • Not enough transparency and accountability:
    1. Lack of proper implementation of SSR1 recommendations, or at least a lack of clear reporting and documentation.
    2. Lack of good measurement, data, and actionable reports on what is actually going on (e.g. lack of important indicators in DAAR, compliance reports). Pricing data being one key gaps.
    • General point: ICANN has in their mission and current objectives to take care of security, they should aim to be a better steward.
  6. Just after the paragraph on DNS, could we add the points that Laurin is making. Something like:

    Specifically,

    • Insufficient contractual provisions and enforcement when it comes to parties harboring systemic abuse (i.e. high rates of abusive registration, lack of cooperation, etc.)
    • Lack of good measurement, data, and actionable reports on what is actually going on (e.g. lack of important indicators in DAAR, compliance reports). Pricing data being one key gaps.

    Generally, ICANN has in their mission and current objectives to take care of security, they should aim to be a better steward.

    Just my suggestion on wording, but I agree with Laurin - a bit more specificity.

  7. To elaborate on my previous comment:

    Re contracts – looking at the ALAC contracts session in "Cancun", we see that, largely, compliance's position is that they do what can / should be done. This means that anti-abuse essentially needs contract change, at least that is what I take away. These could include clearer rules on what is expected anti abuse wise (what measures must be in place), provide clear time frames for dealing with abuse complaints, have compliance investigate those parties that fail to meet these targets / that have high levels of abuse (DAAR data) / lots of complaints. Obviously, there must be some "teeth" to all this, i.e. there must be a stick (plus a carrot that SSR2 proposes)

    On accountability – there seems to be a need for more third party oversight, in whatever way that is implemented In some cases, this could be expert audits (as the community can only do that much, and only has some specialist per issue) or community-based.

    1. Re third party oversight, I agree, but that is something we can emphasize in our comment to the Board after your report is issued. Unless you feel there will be strong push-back to the concept in this comment period.

      I agree that there is a need for more compliance (and likely contract changes) but we really need to avoid going down the PDP road to do that. It is a long and difficult process with dubious benefits in a case like this.

  8. Thanks for the comments. They raise some important issues.

    Note that this is a comment to the Review Team on their draft report and not a comment to the Board. Our message to the Board comes after the final report is issued.

    I suggest adding the following paragraphs prior to the Summary.

    The ALAC has a particular focus on and interest in DNS Abuse. To address this may require contractual changes to facilitate Contractual Compliance action. Such changes require either negotiations with the contracted parties or a PDP. A PDP will take considerable time and the ALAC does not advocate such a path, but rather it is time for ICANN Org and specifically Contractual Compliance to meet with those contracted parties who have shown an interest in DNS Abuse mitigation, and come to an agreement on needed contractual changes, factoring in not only penalties but any incentives that can be reasonably provided to encourage compliance.

    Given the potential for rejection or deferral of the large number of high priority items, the ALAC encourages the review team to strengthen the justification on the number of high priority items.