ICANN ICANN Email List Archives

[gnso-irtp-b-jun09]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [gnso-irtp-b-jun09] 60 day lock following registrant change

  • To: "Gnso-irtp-b-jun09@xxxxxxxxx List" <Gnso-irtp-b-jun09@xxxxxxxxx>
  • Subject: Re: [gnso-irtp-b-jun09] 60 day lock following registrant change
  • From: "Michele Neylon :: Blacknight" <michele@xxxxxxxxxxxxx>
  • Date: Thu, 15 Jul 2010 10:39:15 +0000


On 15 Jul 2010, at 02:04, George Kirikos wrote:
> 
> 
> Furthermore, that still is the case of "security" at the losing
> registrar. If the domain was under VeriSign lock, for example (and not
> all registrars offer it, i.e. differences in security standards at
> different registrars), handing over their account details to an
> attacker is not going to be enough to steal the domain name....the
> losing registrar would have other out-of-band procedures in place to
> contact the registrant, to be very sure about whether they want to get
> the name removed from their "special" or "executive" lock. This
> out-of-band security can happen even at any registrar, regardless of
> whether they use VeriSign lock, by the way. For example,
> Fabulous.com's "Executive Lock"
> 
> http://domainnamewire.com/2008/12/11/fabulous-executive-lock-would-have-saved-checkfreecom/
> 
> where one can have a registrant-defined procedure for changes.


This working group is  discussing transfer _policy_

Transfer policy needs to be applicable to _ALL_ registrants - not just those 
who are willing to pay a premium for extra levels of security etc

Also, the Verisign and Neustar registry locks did not exist when this WG started



> 
> e.g. I might make the procedure be......
> 
> (1) phone me up, and ask me 7 questions where only I and the current
> registrar know the answer, AND
> (2) also ask me to recite a poem that the registrar faxes to a preset
> telephone number in Greek AND
> (3) also ask me to go on Cisco TelePresence video conferencing and
> show a birthmark live on the video chat, while rubbing my tummy in a
> circular motion and patting my head at the same time, while hopping on
> one foot
> (4) AND also give a proper RSA SecurID code during the video
> conference while displaying my authenticator in real-time
> (5) AND also fly to my head office and physically transfer HALF the
> auth-info code to me in a sealed envelope
> (6) AND do all the previous things for a 2nd person at my company!
> 
> (my soon-to-be-patented procedure for .bank changes) ;-) (well, not
> really, but I would suggest parts of #3, #4, #5  and #6 for a .bank,
> if I ran it, amongst other things; feel free to use the above ideas to
> strengthen all registrations, though)
> 
>>> That's really the "elephant in the room". Holding the registrars
>>> responsible both financially and legally creates the proper
>>> incentives
>> 
>> I've never heard of a completed transfer which didn't follow the procedures
>> of the registrars concerned, so what are you expecting to hold them
>> accountable for ?
> 
> Maybe you've not heard of cases like Baidu and Register.com, where the
> employee of the registrar allegedly was duped into making the WHOIS
> changes by the attacker.
> 
> http://www.betanews.com/article/Baidu-Registercom-replaced-its-DNS-credentials-for-some-guy-in-a-chat-room/1267124527
> 
> "Supposedly, he pretended to be Baidu ("Mr. Baidu," perhaps?). And
> although records show the support personnel asked him to verify his
> identity by sending back the security code that was just sent to the
> e-mail address on record as Baidu's authoritative address, the fellow
> instead responded with a made-up bunch of numbers...which the agent
> then accepted as valid."
> 
> "Incredibly, Defendant [Register.com] thus changed the e-mail address
> on file from one that was clearly a business address and contained the
> name of the account owner, to an e-mail address that conveyed a highly
> politically charged message ("antiwahabi"), with the domain name
> ("gmail.com") of a competitor of Baidu, at the request of an
> individual who not only could not produce the correct security
> verification, but actually produced false information twice during the
> verification process."
> 
> Now, that didn't end up being a transfer to a different registrar, but
> it could just as easily have been (since the attacker had de facto
> control of the domain).
> 
> By holding the relevant registrar legally accountable, it's not just
> for following their own "procedures", but for doing proper
> verification/authentication at all times. e.g. if the losing
> registrar's stated procedure is to flash the "auth info" code on the
> Jumbotron at Yankee Stadium, should there be any surprise that an
> attacker uses that "auth info" to hijack the domain name? If the
> "verification" that a registrar does when validating a request to
> unlock a domain constitutes flipping a coin and seeing if it's
> "heads", that's not good enough either.
> 
> Suppose the registrar only offers authentication by email, for
> example, and the registrant's email address is hijacked. If the
> registrar is *still* held legally accountable for a theft (despite
> following all their "procedures"), then that registrar will quickly
> either (1) go out of business or (2) be compelled to upgrade their
> systems. The proper economic incentives are in place for upgraded
> security across the system, because the financial liability is placed
> squarely on the parties most capable of improving overall security.
> 
> Sincerely,
> 
> George Kirikos
> 416-588-0269
> http://www.leap.com/

Mr Michele Neylon
Blacknight Solutions
Hosting & Colocation, Brand Protection
ICANN Accredited Registrar
http://www.blacknight.com/
http://blog.blacknight.com/
http://blacknight.mobi/
http://mneylon.tel
Intl. +353 (0) 59  9183072
US: 213-233-1612 
UK: 0844 484 9361
Locall: 1850 929 929
Direct Dial: +353 (0)59 9183090
Twitter: http://twitter.com/mneylon
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845





<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy