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

[George Kirikos <icann@xxxxxxxx>]

Hello,

On Wed, Jul 14, 2010 at 5:50 PM, Rob Golding
<rob.golding@xxxxxxxxxxxxxxx> wrote:
> None of which is really relevant to whether a *registrar* should be able to
> issue an "undo" on a (suspected fraudulent) domain transfer - there are lot
> of other "uses" of domains beyond the business model of flogging them on a
> 2ndary market

This was *explicitly* in the issues report from last year, as I
mentioned yesterday, that being "suspected" is not enough:

http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00362.html

"The emergency action procedures should be tested to verify they are
resilient to tampering and difficult to exploit. In particular, it
should be difficult or impossible for an attacker to effect a hijack
or interfere with a transfer under the guise of requesting urgent
restoration of a domain." (page 17)

> That only works *if* the gaining registrar agrees, and some of those that
> "aid" in fraudulent transfers are unlikely to do so.

The gaining registrar might have superior information, to know that
it's just not a "fraudulent transfer" that needs to be undone.  Maybe
the gaining registrar is the actual registrant, for example, or has
received proper documentation from the actual registrant (which the
losing registrar for whatever reason doesn't accept). How many times
does one see false/unsupported allegations in UDRPs, or DMCAs, or
other kinds of complaints? As the above language from the issues
report stated, "it should be difficult or impossible for an attacker
to effect a hijack
or interfere with a transfer under the guise of requesting urgent
restoration of a domain." That "attacker" could be the prior
registrant, for example.

Stepping back, as discussed numerous times, the superior solution is
to make sure that proper authorizations/verifications take place
proactively, before the change is "committed" to the registry. The
losing registrar could and should have done so before allowing the
WHOIS to update, before allowing a domain lock to be removed, and
before releasing the auth_info code.

>> [If the purchaser does the change of registrant entirely at the old
>> registrar, with the desire to them move it to their favourite
>> registrar, then they'd have to deal with situations like that at
>> GoDaddy, where potentially the name is forced to stay there for 60
>> days
>
> Based on your earlier arguments, surely that would be a-good-thing(tm)...

Being stuck at a registrar you don't want to be at? I don't think
that's a "good thing(tm) at all.

> Registrants get fooled by this process used by domain-scum-of-(location),
> and at the point of handing over such details, lose control over/services
> for their domain as a direct result of being "conned" by a "sales-technique"
> which is a criminal offence in UK law.
>
> That is a very real problem, and not one of "security" at the losing
> registrar, but one of sad-but-true stupidity of the registrant.

People sign "bad deals" all the time, and need to take responsibility
for their own actions. If the transfer followed the "letter of the
process", then it should be left to the legal system (police, courts,
etc.) to determine if it's fraud. By all means, improve the "letter of
the process", but at some point "what's done is done" within the
registration system itself, and one must go to an outside authority to
deal with legal disputes.

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.

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/