[CPWG] FW: Engagement on DNS Abuse
Carlton Samuels
carlton.samuels at gmail.com
Thu Feb 4 16:33:08 UTC 2021
Hi Laurin:
One of the things I learned from public policy advocacy in my home region
is to be avowedly incrementalist if one should not lose heart. So I would
take it as progress and a big win if we commit to simply enforcing the
rules already!
You would have seen my colleague and friend Evan's intervention. He and I
have been at this matter since 2009, the apogee of those engagements
coinciding with the emergence of the 2013 RAA. The [then] preponderant
At-Large view hews somewhat to one framed by a justice of the U.S. Supreme
Court when asked how he could tell if something was obscene; his pithy
response " *I know it when I see it*". In a funny kind of way, end users
tend to know abuse when they feel it. And there's the rub.
As John McCormac rightly pointed out in respect of DNS Abuse, the struggle
now is no longer definitional but on scope. And the argument is inebriated
- yes, made drunk! - by the circular is this determined by detection or
reporting.
Our colleagues in aa419 and Legitscript will tell you regardless, the fight
for each is only from different fronts. I tend to agree with this. So, the
struggle continues.
Carlton
==============================
*Carlton A Samuels*
*Mobile: 876-818-1799Strategy, Process, Governance, Assessment & Turnaround*
=============================
On Wed, Feb 3, 2021 at 1:27 PM Laurin B Weissinger <Laurin-lists at pm.me>
wrote:
> Dear Carlton and all,
>
> Yes, technically some of these things might exist to a greater or lesser
> extent on paper, some do not (I recently had the pleasure reading the
> publicly available documents). However, no matter what is on paper, they
> clearly do not exist/are not applied in practice.
>
> Furthermore, as you rightly state, ICANN is not enforcing the clauses that
> are there. (Alpnames comes to mind as well as others). This is a problem.
>
> The issue is clearly unwillingness to change on the part of certain
> parties, which is only rational considering their business interests.
> Furthermore, it is obvious that perfect security is impossible and that
> expense must be balanced against the usefulness. Without any doubt, we are
> far far away from that point.
>
> Nevertheless, (continued pressure to establish) new policies are needed.
> From a public safety and security perspective, things need to change.
>
> All the best
> Laurin
>
> P.S. The SSR2 report addresses this as well. If correctly / in a useful
> way — I don’t know.
>
> On Wed, Feb 3, 2021 at 17:55, Carlton Samuels <carlton.samuels at gmail.com>
> wrote:
>
> Laurin wrote:
> * Again, speaking from SSR2 experience: focus can be put on forcing
> immediate review in case of reports, allowing bulk reports, introducing
> hurdles for criminals on registration, pre-review of suspicious names, etc.
> (I.e. do things that reduce abuse before it happens)*
>
> Have to tell you that IMHO, all of that - what normal regulators would
> shop as KYC rules - is covered in existing [RAA and RRA] contracts and/or
> consensus policies. The problem is for the most part, some of our brethren
> have declared them one or other of burdensome to transaction
> processing/alien to businesses operating at internet speed/not commercially
> reasonable/plain abusive of registrant rights. And as intimated in the
> thread, ICANN CC has shown neither appetite to enforce or the gumption for
> enforcement.
>
> The arguments I've heard since time out of memory to justify inaction is
> the concern that Compliance not overstep the general ICANN obligations
> detailed in the RAA. Never mind that there is a specific clause in the
> RAA that compels the Registrar to collect "*accurate and reliable contact
> details*" along with some indicative responses when those are in doubt!
>
> There is a [WHOIS] Accuracy Specification which outlines the expectations
> for accurate and reliable registration data. That Specification also
> outlines in clear text the responses when otherwise suspected. Some of us
> have argued that fifteen (15) days before effective corrective or coercive
> [re]action - suspend the ability for name resolution! - was totally out of
> whack to damage that could be wrought on end users.
>
> Then there is a specific clause in the RAA that enjoins the Registrar to
> keep the data collected safe and sound. And one that enjoins the Registrar
> to share it, as necessary and requested, with a court of lawful
> jurisdiction.
>
> I personally don't see how one can say a registered name holder is '*identified
> and identifiable*' without verification of the elements used to establish
> identity. I also know that knowingly sending inaccurate data to a court of
> lawful jurisdiction is, in some [common law] jurisdictions, deemed an
> abuse of process and contempt of court.
>
> Interestingly, there is a clause in the RAA that enjoins a Registrar not
> to activate a name until they are sure of payment! That same rule devolved
> and applied to establishing identity is a no brainer. But nooooooo.....
>
> Carlton
> ==============================
> *Carlton A Samuels*
>
> *Mobile: 876-818-1799Strategy, Process, Governance, Assessment &
> Turnaround*
> =============================
>
> On Wed, Feb 3, 2021 at 10:27 AM Laurin B Weissinger via CPWG <
> cpwg at icann.org> wrote:
>
>> Dear all,
>>
>> My comments, adding onto Johanna’s:
>>
>> Keeping these in mind the proposed definition and scope of DNS Abuse
>> strikes as arbitrary: what were the criteria set for selecting these
>> specific categories as DNS Abuse while leaving other potential categories
>> out?
>>
>> The perspective I am getting from SSR2 is to start with the obvious,
>> technically detectable ones: phishing, C2, plus reports of those.
>> Essentially, stop crimes in progress that do not require complicated and
>> long human oversight.
>>
>> I am worried about including issues that are private disputes. Even if
>> many use Copyright to stop crimes in progress, as it is the only thing that
>> works. (Consider how insane this is: I need to use the fact that someone is
>> using my logo not as evidence but as a CR issue to stop an actual crime in
>> progress.)
>>
>> Including IP infringement on equal footing with CSAM raises serious
>> concerns among At-Large members
>>
>> Absolutely agree with Johanna on the CSAM aspect. It is, imho, ridiculous
>> and more so offensive to name _private_ copyright _disputes_ alongside
>> CSAM.*
>>
>> Again, speaking from SSR2 experience: focus can be put on forcing
>> immediate review in case of reports, allowing bulk reports, introducing
>> hurdles for criminals on registration, pre-review of suspicious names, etc.
>> (I.e. do things that reduce abuse before it happens)
>>
>> All the best
>> Laurin
>>
>> * Indeed, beyond this being ethically and morally unacceptable, companies
>> (not gonna name names) use copyright complaints to silence their critics
>> (free speech issue), arguably themselves being abusers of the system, at
>> least in some cases.
>>
>>
>> On Wed, Feb 3, 2021 at 15:49, Jonathan Zuck <JZuck at innovatorsnetwork.org>
>> wrote:
>>
>> Evin has suggested that I had, perhaps, NOT forwarded this to the group.
>> Here’s the discussion thread, initiated by Keith Drazek on the Contracted
>> Party House DNS Abuse Work Group. This includes, Joanna’s expression of
>> mission creep concern.
>>
>> Jonathan
>>
>>
>>
>>
>>
>> Jonathan Zuck
>>
>> Executive Director
>>
>> Innovators Network Foundation
>>
>> www.InnovatorsNetwork.org
>>
>>
>>
>> *From: *Joanna Kulesza <jkuleszaicann at gmail.com>
>> *Sent: *Wednesday, January 27, 2021 2:12 AM
>> *To: *Maureen Hilyard <maureen.hilyard at gmail.com>; Jonathan Zuck
>> <JZuck at innovatorsnetwork.org>
>> *Subject: *Re: Engagement on DNS Abuse
>>
>>
>>
>> Great stuff Jonathan, as always. Feel free to share. If I were to add my
>> two cents, I'd put these in the "pain points" section while these are of a
>> more general nature.
>>
>> "From the discussions we've had within At-Large it is clear that the very
>> scope and definition of DNS Abuse is a "pain point". This was also the take
>> away from the discussions we've had with the invited guests from within and
>> beyond the ICANN community. "DNS Abuse" as it is now defined in the
>> proposed Framework affects the entire internet community of end users while
>> being already covered by existing national and international norms and
>> standards. Keeping these in mind the proposed definition and scope of DNS
>> Abuse strikes as arbitrary: what were the criteria set for selecting these
>> specific categories as DNS Abuse while leaving other potential categories
>> out?
>>
>> This is particularly relevant with regard to our second concern: the
>> proposed scope of DNS Abuse clearly crosses the content "picket fence" that
>> the ICANN community had set for itself. Including IP infringement on equal
>> footing with CSAM raises serious concerns among At-Large members. We are
>> concerned not only with the very fact of the picket fence being crossed but
>> also by the way in which this is being done. Does this mean we should
>> finally abandon the well established yet always controversial narrative of
>> a strictly technical infrastructure management?
>>
>> Once content is concerned, the existing and proposed practice fails to
>> recognize international legal safeguards when it comes to restrictions put
>> on individual freedoms. Whenever an individual liberty is to be restricted,
>> due process must be ensured. The procedures proposed by the DNS Abuse
>> framework fail to ensure e.g. a right to an effective legal remedy. While
>> we realize this argument brings us back tot he general discussion on limits
>> of ICANN's contractual jurisdiction, that is an argument we would be
>> interested to during any upcoming DNS Abuse work.
>>
>> Only once these concerns relating to the scope of the definition of DNS
>> Abuse can be addressed, can we focus on metrics and effective enforcement
>> that will provide a fair and operational framework protecting the rights of
>> end users."
>>
>> By all means to feel free to rephrase!:) What I'm arguing for is that for
>> us to be able to "measure" DNS Abuse we should first clearly and
>> transparently decide what it means. The current framework means the
>> contracted parties are indeed trying to play a self-proclaimed internet
>> police (militia?). Why did we presume DNS Abuse is CSAM and (in the same
>> breath) fake Gucci bags but not hate speech and inciting violence? While we
>> clearly would not have the answer ready, that is definitely a discussion we
>> should have. The GAC might be interested in this as well (see last update
>> from Veni on the ITU processes).
>>
>> Thanks for considering team!
>>
>> Best,
>>
>> J.
>>
>>
>>
>>
>>
>> W dniu 27.01.2021 o 01:39, Maureen Hilyard pisze:
>>
>> In your inimitable style. Love it. Send it.
>>
>>
>>
>> M
>>
>>
>>
>> On Tue, Jan 26, 2021 at 12:34 PM Jonathan Zuck <
>> JZuck at innovatorsnetwork.org> wrote:
>>
>> Ladies,
>>
>> Here’s my draft response. Let me know what you think!
>>
>> Jonathan
>>
>> =============================================================
>>
>> Hey folks! Thanks for reaching out. Joanna and I, for sure, would be
>> willing to join you and I suspect others, as well, once we know the timing.
>> With respect to the questions below, I’ll do my best to provide some
>> initial responses but I suspect the first question might be pivotal. There
>> seems to be a lack of real data on the topic and perhaps some additional
>> objective research is the answers. We endeavored to begin this process,
>> during the CCTRT (sadag-final-09aug17-en.pdf (icann.org)
>> <https://www.icann.org/en/system/files/files/sadag-final-09aug17-en.pdf>,
>> but obviously barely scratched the surface. Perhaps a more comprehensive
>> study, funded by ICANN rather than the CPH or CSG might be in order? I know
>> DAAR provides some answers but it seems to be more of a survey than an
>> example of rigorous research. Specifically to your questions.
>>
>>
>>
>> 1. *What information do you use and how do you use it to assess DNS
>> Abuse levels?*
>> This is obviously where we are weak. There doesn’t appear to be a
>> great source for DNS Abuse “levels,” particularly because of the short time
>> period over which a particular initiative takes place. A snapshot analysis
>> doesn’t seem to get the full picture. The ALAC relies on the concerned
>> raised by the GAC and the SSAC to fuel our belief that there’s more we
>> should be doing. A recent report from Microsoft suggests the problem is
>> bigger than we realize and David Taylor’s analysis of “responsiveness,”
>> even among those who have signed onto the framework, seems damning.
>> 2. *What are the ALAC’s pain points regarding DNS Abuse?*
>> Not sure to answer this in terms of how it’s handled inside ICANN or
>> more generally from where our interests stems. To the latter point, we’re
>> tasked with advancing the interests of those not represented by a
>> constituency in the GNSO, namely those engaged in everyday use of the
>> internet, as opposed to registrants. As the user base continues to grow, as
>> we all desire, so too will the numbers of less sophisticated users, more
>> easily duped by a phishing, malware or fraudulent advertising attack.
>> As for the situation inside ICANN, the At-Large community have
>> attempted to engage constructively as opposed to “attacking” the CPH,
>> focusing instead on so-called “bad actors.” The first session
>> <https://community.icann.org/display/atlarge/At-Large+Meetings+-+Monday%2C+09+March+2020?preview=/124847126/126428447/CCWholistic02.pdf>
>> was an attempt to bring the CPH and Contract Compliance into the same room
>> to figure out where the holes are.
>>
>>
>> 1.
>> *What exactly are the relevant limits on Contract Compliance? *We feel
>> this is a question which comes up constantly and is never successfully or
>> consistently answered. It seems to be an area in which the ICANN community
>> is constantly chasing it’s tail. It would seem that the only real enforced
>> contract provision is payment. I’m sure this is an exaggeration but it
>> seems to be a repeated situation where that is ultimately what foils a “
>> bad actor” after YEARS of neglect, if not outright facilitation of abuse.
>> The answer to THIS question should be a HIGH priority. It might just be
>> agreeing to an interpretation of the contracts or it might require an
>> amendment to the contracts but this issue needs to stop being a merry go
>> round.
>> 2.
>> *Insufficient Transparency from Contract Compliance *Contract Compliance
>> undocumented endeavors at soft touch diplomacy with bad actors seem to need
>> some better limits or, at least, transparency. For “the market” to play a
>> role in this, knowing about legitimate complaints for every contracted
>> party could help customers make better decisions about which businesses to
>> use and help us better understand where policy development needs to take
>> place.
>> 3.
>> *Deflection and Minimization of the Problem *I would say that one “pain
>> point” is that our efforts have been largely “trolled” by certain members
>> of the CPH, rather than engaging constructively. EVEN our effort to
>> conceive of some sort of end user education campaign, to take the pressure
>> off the CPH, was trolled. Jim, not to put you on the spot but, during one
>> conversation, you said you didn’t even understand why this was being
>> discussed because it affects such a small percentage of registered names.
>> To date, we have proposed:
>>
>> *i.* *Better
>> contract enforcement*
>>
>> *ii.* *More
>> tools for Contract Compliance*
>>
>> *iii.* *DNS
>> Abuse “threshold,” an idea that found some support among the CPH at one
>> point*
>>
>> *iv.* *Predictive
>> Analytics platform, perhaps financed by ICANN*
>>
>> The At-Large community has *absolutely* no desire to over regulate or
>> over tax the CPH and we understand most of the contracted parties,
>> particularly those showing up to meetings, are trying to do well and
>> continuously improve. That said, this notion that it’s somehow not “our
>> place,” to be trying to help is nothing short of offensive. It is the
>> active participation of the ALAC and GAC that enable the ICANN to portray
>> itself as something other than a trade association. The At-Large mandate is
>> to advance the interests of those MOST impacted by DNS Abuse. That said, we
>> WELCOME suggestions on how better to engage with the CPH for constructive
>> outcomes.
>>
>>
>>
>> 1. *Are you seeing practices from registrars or registries you find
>> helpful?*
>> If we haven’t said it enough, the At-Large appreciates the efforts of
>> those behind the Framework for DNS Abuse and the huge efforts that went
>> into cooperation with law enforcement to track down COVID related abuse.
>> We’d love to see the framework evolve to include specific commitments and
>> metrics, however, for it to be something on which the community could truly
>> rely.
>>
>>
>>
>> We hope these answers are constructive and not inflammatory as it is our
>> intention to find the most effective ways to proceed to further minimize
>> the incidence of DNS Abuse , in all its forms. Thanks for the opportunity
>> to be part of your conversation.
>>
>>
>>
>> Maureen, Joanna & Jonathan
>>
>>
>>
>>
>>
>>
>>
>> *From: *Keith Drazek <kdrazek at verisign.com>
>> *Date: *Friday, January 22, 2021 at 12:00 PM
>> *To: *"maureen.hilyard at gmail.com" <maureen.hilyard at gmail.com>, Jonathan
>> Zuck <JZuck at innovatorsnetwork.org>, "jkuleszaicann at gmail.com" <
>> jkuleszaicann at gmail.com>
>> *Cc: *"Brian F. Cimbolic" <BCimbolic at pir.org>, Jim Galvin <
>> jgalvin at afilias.info>, Graeme Bunton <gbunton at tucows.com>
>> *Subject: *Engagement on DNS Abuse
>>
>>
>>
>>
>>
>> Hello Maureen, Jonathan and Joanna,
>>
>>
>>
>> I hope you’re all doing well and staying healthy and safe. I am reaching
>> out to you on behalf of the Contracted Party House DNS Abuse Working Group
>> as we look ahead to ICANN 70 and the rest of 2021.
>>
>>
>>
>> The Contracted Party House (CPH) DNS Abuse Group is conducting outreach
>> to our friends in other SO/AC/SG/Cs regarding DNS Abuse. As previously
>> noted by the CPH, DNS Abuse
>> <https://rrsg.org/wp-content/uploads/2020/10/CPH-Definition-of-DNS-Abuse.pdf>
>> comprises five categories: phishing, pharming, malware, botnets, and spam
>> when it acts as a delivery mechanism for one of the other forms of DNS
>> Abuse.
>>
>>
>>
>> We want to open a more direct dialogue to understand pain points, hear
>> suggestions and identify common ground where we can work together to
>> mitigate DNS Abuse. Is there a subset of the At-Large focusing on DNS
>> Abuse questions that would be able to join the CPH DNS Abuse group on a
>> call to discuss this topic? We want to encourage frank and productive
>> discussions on the topic that lead to really informing our dialogues and
>> actions.
>>
>>
>>
>> As a starting point, we propose the following questions to guide our
>> discussion. Are there any other questions ALAC would like discuss?:
>>
>>
>>
>> What information do you use and how do you use it to assess DNS Abuse
>> levels?
>>
>>
>>
>> What are the ALAC’s pain points regarding DNS Abuse?
>>
>>
>>
>> Are you seeing practices from registrars or registries you find helpful?
>>
>>
>>
>> Please let us know if a subgroup of the ALAC would be willing to join
>> us. Our group meets regularly on Tuesdays at 1500 UTC. If so, please
>> propose a Tuesday when you are available.
>>
>>
>>
>> Best regards,
>>
>> Keith
>>
>>
>>
>> Keith Drazek
>>
>> Vice President, Public Policy & Government Relations
>>
>> Verisign, Inc.
>>
>> +1-571-377-9182
>>
>> Kdrazek at verisign.com
>>
>>
>>
>>
>>
>> --
>>
>> Kind regards,
>>
>> Joanna Kulesza
>>
>> -------------------
>>
>> Joanna Kulesza, PhD
>>
>> University of Lodz, Poland
>>
>> ICANN ALAC Vice Chair
>>
>> SOI: https://community.icann.org/display/atlarge/Joanna+Kulesza+SOI
>>
>> TT: @KuleszaJ
>>
>>
>>
>>
>>
>> _______________________________________________
>> CPWG mailing list
>> CPWG at icann.org
>> https://mm.icann.org/mailman/listinfo/cpwg
>>
>> _______________________________________________
>> By submitting your personal data, you consent to the processing of your
>> personal data for purposes of subscribing to this mailing list accordance
>> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
>> the website Terms of Service (https://www.icann.org/privacy/tos). You
>> can visit the Mailman link above to change your membership status or
>> configuration, including unsubscribing, setting digest-style delivery or
>> disabling delivery altogether (e.g., for a vacation), and so on.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cpwg/attachments/20210204/ea5c5365/attachment-0001.html>
More information about the CPWG
mailing list