[CPWG] Atrt3 public comment

[Laurin B Weissinger]

Dear all,

Unfortunately, I will not be able to join the CPWG call today. My apologies

First, as one of the penholders for ALAC, I will go with what is consensus. I will, however, post my concerns individually depending on what the consensus call will be.

Second, I am talking about SSR because this is what I do, have studied and worked in for years — but some points apply more broadly.

Third, I have to give a talk in a few minutes, please excuse brevity and bad style.

Regarding the ATRT3 comment:

Stability, Resiliency, and Security, which includes integrity, availability, and confidentiality, are what matters to registrants and the people who rely on identifiers. The only key concern I see that is not SSR is pricing / competition and even that interacts and intersects a lot (abuse).

I am very worried about the push to reduce the SSR review to short workshops, or similar. They are not at all superfluous. I could post many many references to how security management needs external review but I won’t bore you. SSAC and RSSAC give advice, they do not audit / review.

Many approaches to doing this are fine, the key to all of them is to have actual **oversight, transparency, and consequences / actions to address SSR concerns** (i.e. not the status quo). Continuous assessment sounds good and would be useful but how that would happen needs to be fleshed out because the current system is not working and internet users are at risk every day. For example, ICANN contracts do not address systemic abuse (think alpnames and their 50%+ of new registrations blacklisted by spamhaus), or because minimum standards are not enforced like in other industries: e.g. payment industry, health, etc.  DAAR, i.e. just data no actual action, is severely lacking; no data on who is enabling abuse so that administrators can address that attack vector. Further info in the early draft report released by SSR2 for public comment for perspective on how things are looking.

Again, it is not working right now and we need to have oversight of these key issues, and the solution is not to reduce transparency of security matters but to increase it. The issue is not just burnout but that people are not heard on security, as security costs ICANN and contracted parties money. I consider security costs to be okay; ICANN is the steward of the DNS and their job includes providing functional, global resolution as well as protecting users from being abused through the infrastructure. If you cannot provide base line levels of controls, maybe you shouldn’t offer these services.

Options or approaches I consider appropriate:
- Have short but **more frequent** reviews on SSR, e.g. twice per year. With people having overlapping terms (at least 1 year overlap, better 1.5/2) to ensure knowledge transfer.
- Retain SSR reviews but get ICANN to support it properly (unlike SSR2), that will speed things up considerably. I can tell you many stories, e.g. our support being cancelled without discussion with the team.
- Get a proper certification and **audit** regime in place (org so far doesn’t want that): iso27k, staff certification, iso9k, etc etc. Do external, third party audits like any org like ICANN should — and **publish** (summary) reports.
(In short, many options).

Different but key point:
- ICANN has **not** taken anti-abuse and security seriously, and it remains a key issue for users, again more academic studies and references on this than I can count. Just look at Dave P’s bog. Whatever the regime will be chosen, it must ensure that ICANN is taking security seriously, that there is actual oversight (not like we have it now where security-relevant data and information are not made available), and that there are actual *consequences* when ICANN fails to take this seriously. SSR might be a key element of the strategic plan but whatever atrt goes with should ensure that ICANN is actually held to this.

ICANN org saying that SSR concerns have been addressed is **not enough**, we know that we cannot rely on that call because of what SSR and other reviews find. We need that external check.

All the best
Laurin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cpwg/attachments/20200129/dbaaa3eb/attachment.html>