[ALAC] Domain Hijacking - For Discussion and Action

Fri Feb 7 03:58:30 UTC 2014

Hi Garth and Alan

This is absolutely important.

I am sitting on the ITRP-D Working Group, and one of the issues we have been looking at is what to do if a registrant loses 'their' name.  One of the issues is clearly registrant education and the whole WG agrees that there is nothing on the ICANN website that is easily found (and understood) that explains both when ICANN can do something - and when they can't. 

The example that Alan cited is one we also discussed.  There are many times (as said on the teleconference calls) when the problem is not ICANN's - it is a web designer who doesn't pass the name to the person/business.  Or it is someone in the organisation who is the listed contact - and then leaves and either forgets - or deliberately does not change the contact details. Or there is a dispute within a company and the right - or wrong - person gets the name.  ICANN can't (and probably shouldn't) be involved.  But the SSAC advice is really helpful (once you have trawled through their reports).  And a really good fact sheet or two would also be helpful.  Indeed, the Registrants Rights document that was passed in June would be really helpful if it had more detail.

Sometimes - if it is something that has happened that is contrary to ICANN policy/the RAA, ICANN can do something. 

One thought that was floated in the ITPR-D was whether to involve the Ombudsman, but his jurisdiction is limited and the best he can do is send people off to Compliance if it is in their jurisdiction. 

So yes, get stats if you can.  And I'm sure GNSO people have PLENTY of examples as to how hijacking occurs

As to the SSAC, Patrik would have plenty to say.  But Dave Piscatello has also been really helpful at times - do get in touch with him.  He was the one - years ago now - that talked about initial studies on the whois issue.

Holly

On 07/02/2014, at 3:28 AM, Garth Bruen wrote:

> Thanks Alan,
> 
> I'm going to add the topic as a discussion item for our Monday call as well
> as the meeting in Singapore. 
> 
> Since this is an issue which affects all regions I will post the question to
> the other officers as well. To start with:
> 
> * If we have compliance or legal slatted to come to the ALAC sessions
> perhaps we can have them produce some information on how many hijacking
> complaints they get and how they are handled. 
> 
> * We need some statistics on the problem, I'll start probing around for
> experts. 
> 
> * We'll need an overview of how domain hijacking occurs - perhaps we can get
> some real victims to speak
> 
> * The discussion should include a review of the SSAC reports and current
> policy initiatives
> 
> I'm glad for the RAA changes, and I think registrant education is key. In
> this case I'm wondering if the registrar violated the registrant's privacy
> by giving out additional information to the attacker that was not public.
> I'm also concerned that these cases are dismissed out of hand by ICANN as
> being "customer service related."
> 
> I'll come up with an agenda list and send it to the group.
> 
> -Garth
> 
> 
> 
> 
> -----Original Message-----
> From: Alan Greenberg [mailto:alan.greenberg at mcgill.ca] 
> Sent: Wednesday, February 5, 2014 2:02 PM
> To: Garth Bruen; 'ALAC Working List'
> Subject: Re: [ALAC] Domain Hijacking - For Discussion and Action
> 
> Thanks for raising this Garth.
> 
> I agree that this is an issue worthy of At-Large focus, and I encourage
> that.
> 
> There has been significant focus on the issue of hijacking, and those who
> want to further understand what the issues are and how to address them
> should consult the IRTP-B report (pointed to by
> https://community.icann.org/pages/viewpage.action?pageId=12746774) as well
> as SSAC reports SAC044
> (http://www.icann.org/en/groups/ssac/documents/sac-044-en.pdf) and SAC044 (
> http://www.icann.org/en/groups/ssac/documents/sac-040-en.pdf).
> 
> IRTP-B focused on a number of hijacking issues and resulting in a number of
> RAA changes to help ensure that if a domain is hijacked, it can be recovered
> swiftly. It also recommended that a PDP be considered on requiring a thick
> whois for all TLDs, a recommendation which resulted in a PDP and the
> resultant PDP recommendation which is to be considered by the Board at a
> meeting later this week.
> 
> The PDP also specifically recommended that ALAC (among others) help in
> registrar education to help protect registrations (Recommendation 2). I note
> that to date we have not done a lot of that (that I can recall).
> 
> SAC044 focuses on protecting registrations from a registrar's point of view,
> and SAC044 from a registrant's point of view.
> 
> The issue is particularly timely, due to an issue that is seemingly
> unrelated but is in fact closely linked. The ALAC is currently in the
> process of considering an application from a prospective ALS and during the
> vote, it was discovered that their web site no longer functioned. On further
> investigation, it seems that their domain name had expired without being
> renewed. And it could not easily be renewed because the entity listed as the
> registrant (a person at web design
> company) apparently was no longer around. Taking control of the domain to
> renew is, for all practical purposes (from the registrar's point of view)
> very difficult to distinguish from hijacking. How to address such a VERY
> common occurrence while at the same time avoiding ill-intended change of
> registrants is somewhat of a challenge.
> 
> I welcome further thoughts on the issue, and suggestions of how to proceed.
> 
> Alan
> 
> 
> 
> At 02/02/2014 04:43 PM, Garth Bruen wrote:
>> Dear Colleagues,
>> 
>> This is an ugly topic which has come up frequently but for which little 
>> has been done. Thanks to Dev, I have become aware of a high-profile 
>> domain theft case in my region. Because the victim is in the United 
>> States I am bringing he concerns to the community and will be pushing 
>> for serious attention on the problem. The full story can be found here:
>> https://medium.com/p/24eb09e026dd, but basically an attacker used 
>> various social engineering methods to steal a domain name and then used 
>> it as collateral to steal a Twitter account from the same person. Here 
>> the domain was the vector and not the target, but it does not matter. 
>> The domain should have never been hijacked.
>> 
>> The registrant in the case did everything right: paid bills, didn't 
>> abuse the domain name, a model domainer. There is clearly something 
>> very wrong with the way registrant identities are verified (or not) and 
>> a lack of procedure on ICANN's end for dealing with these domain customer
> issues.
>> Obviously, the Twitter issue is beyond our prevue but the domain theft 
>> here could happen to anyone of us.
>> 
>> In Buenos Aires I presented two cases to At-Large: 1) A 
>> non-English-speaking community group in Asia/Pacific who has their 
>> domain hijacked and did not even know where to begin to get help and 2) 
>> The case of Frederick Harris who claims he brought his hijacking case to
> Compliance and was turned away:
>> http://www.circleid.com/posts/20131021_icann_can_not_be_trusted_to_prot
>> ect_d
>> omain_registrants/
>> 
>> There are multiple problems here starting with the registrant's 
>> information not being protected, to using payment systems as 
>> identification, to registrant education, to poor customer service, to a 
>> lack of process at ICANN, etc. etc.
>> 
>> I'm calling here for the beginning of a true look into the problem, 
>> it's extent, and possible solutions.
>> 
>> Thanks, Garth
>> 
>> 
>> -------------------------------------
>> 
>> Garth Bruen
>> Chair of ICANN At-Large North America (naralo.org)
>> http://www.linkedin.com/pub/4/149/724
>> 
>> "If history is deprived of the Truth, we are left with nothing but an 
>> idle, unprofitable tale" -Polybius
>> 
>> 
>> 
>> _______________________________________________
>> ALAC mailing list
>> ALAC at atlarge-lists.icann.org
>> https://atlarge-lists.icann.org/mailman/listinfo/alac
>> 
>> At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki:
>> https://community.icann.org/display/atlarge/At-Large+Advisory+Committee
>> +(ALAC)
> 
> 
> _______________________________________________
> ALAC mailing list
> ALAC at atlarge-lists.icann.org
> https://atlarge-lists.icann.org/mailman/listinfo/alac
> 
> At-Large Online: http://www.atlarge.icann.org
> ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)