[CPWG] FW: Engagement on DNS Abuse

Wed Feb 3 17:08:14 UTC 2021

Good email John, covers a lot. 

While price is a factor, lets not forget that threat actors like Emotet were responsible for 36-40% of all malware distribution for many years. 
This crime as a service operator was doing pretty well into hacking Wordpress installations of legitimate domain name owners with a Wordpress installation. 

The CPH DNS Abuse framework is pragmatic in the sense that it covers what CPH's can do on their technical level. 
However, the reality is a lot of cybercrime cannot be addressed on the CPH technical level. 

We currently ingest 72 blocklists and cyber intelligence feeds and our current reality is that 2% is pure domain name abuse, 6% is on a hostname level and 92% is URL/Content abuse. Our data goes till 2014. 

URL/content abuse is very problematic to address (often impossible) as a registrar and as many of you heard the reasons for many years I am not going to repeat them. 
But as a community we need to be very sensible and not conflate all kinds of abuse and indeed get a good understanding what is DNS Abuse and what can actually be done within the ICANN remit and be realistic of the technical reality what CPH's can do. 
If we want to remain relevant on this topic we need to push ahead and come up with solutions that address the issues we actually can address. 

Best, 
Theo 

On Wed, Feb 3, 2021, at 4:46 PM, John McCormac wrote:
> On 03/02/2021 14:49, Jonathan Zuck 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.
> 
> It looks like the term "DNS Abuse" has been arrived at but the scope is 
> still unclear. The mission creep angle is important. Without a clear 
> definition of what constitutes DNS Abuse, the conversation is just going 
> to go round in circles.
> 
> The DAAR and other approaches rely upon reporting. The majority of the 
> blacklists it uses seem to depend on reporting rather than detection. 
> This means that potentially only a small part of the problem is 
> identified. Moving from a reporting model to a detection model is 
> difficult and given the limited resources and expertise of ICANN, it 
> would not be possible for ICANN to monitor all websites for a detection 
> based model. And the definition of DNS Abuse also, I think, covers 
> e-mail spam and DDoS. So not only would a detection based system have to 
> cover websites, it would also have to cover DNS and mailserver 
> monitoring. The snapshot point mentioned in the thread is a good one 
> because it will miss the transition of latent bad actor domain names to 
> actively abusive domain names/websites.
> 
> With website detection, the problem is one of depth rather than width. 
> The number of active websites (non-templated PPC/parking/holding 
> content) in most well used TLDs is around 30%. Some of the new gTLDs 
> have active site levels below 10%. The ccTLDs generally have a higher 
> active usage %. When it gets to problems like phishing, the phishing is 
> often done in a subdirectory of the main website and may not be 
> accessible from the site's links.
> 
> Problem websites involving Intellectual Property are often quite 
> obvious. The low registration fee of some of the zone-stuffer new gTLDs 
> has facilitated a shift of much of this kind of activity from the legacy 
> gTLDs. (This was mentioned in the (SIDN?) study that the CCT cited.)
> 
> The definition of "DNS Abuse" needs to be clear. Then it needs to be 
> quantified.
> 
> Making registries and registrars responsible for the problem may seem 
> like a good approach when the definition of the problem and the scale of 
> the problem are unknown. It is not a good approach.
> 
> Putting registries and registrars in the position of having to monitor 
> and deal with everything changes their position from being effectively 
> "common carriers" to one where they are in a position of editorial 
> control. With Section 230 of the CDA in the US coming up for review, 
> that could put the registries, registrars and ultimately ICANN (it still 
> is a US company) in some bother if S230 is revoked or amended. The 
> current model of having registrars and registries take action on serious 
> problems but leaving the IP issues to the lawyers to sort out is 
> probably the best one at the moment and it is working.
> 
> The inclusion of "hate speech" as DNS Abuse is serious mission creep 
> because it is a highly subjective issue. Leave that to the local 
> legislative frameworks.
> 
> The comments in that e-mail about defining the issue are important. The 
> worst thing that could be done is for everyone to go off with their own 
> definition of what should constitute DNS Abuse and then start arguing 
> about why their view matters more than others. ALAC and the other 
> parties will end up with years of futile arguments while little or 
> nothing will be done to solve the problems. And as a bonus, the threat 
> landscape of DNS Abuse is continually changing as new techiques are 
> developed and older ones fall out of use. (e.g link injection 
> (monetisation of abuse) on websites overtaking website defacements 
> (ego/political abuse))
> 
> The Precog approach with predictive analytics may sound impressive but 
> the reality is that to be effective, it would need more than the past 
> history of registrants. That brings up the concept of bad registrars and 
> bad TLDs. Getting access to some of the financial data for a better 
> predictive model might not be possible due to registries and registrars 
> having multi-jurisdictional markets.
> 
> Anecdotally, many mailserver admins have taken to blocking the new gTLDs 
> on their servers because all they see from them is spam. URLs from some 
> heavily discounted new gTLDs in some ccTLD or country level web usage 
> surveys are strong indications of a compromised website.
> 
> It would appear that the fact that a boom and bust model of heavily 
> discounted registration fees would result in abusive registrations was 
> ignored in the 2013 round. Unfortunately, it was all too obvious to 
> people who have to deal with the results. But then ICANN's numerology 
> projections cluelessly expected 35 millon new gTLD registrations in the 
> first year.
> 
> A minimum resale price would be one way of limiting the effect of 
> organised DNS Abuse but it might directly impact the financial viability 
> of some gTLDs in future rounds. Existing gTLD operators would also 
> object as the boom and bust model is their only model since Brand 
> Protection registrations were effectively taken out of their 
> projections. Without the guaranteed revenue from brand protection 
> registrations, some of the new gTLDs didn't have much of a market left.
> 
> Regards...jmcc
> -- 
> **********************************************************
> John McCormac  *  e-mail: jmcc at hosterstats.com
> MC2            *  web: http://www.hosterstats.com/
> 22 Viewmount   *  Domain Registrations Statistics
> Waterford      *  Domnomics - the business of domain names
> Ireland        *  https://amzn.to/2OPtEIO
> IE             *  Skype: hosterstats.com
> **********************************************************
> 
> -- 
> This email has been checked for viruses by AVG.
> https://www.avg.com
> 
> _______________________________________________
> 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/20210203/69413745/attachment.html>