Re: [SPAM] [gnso-irtp-b-jun09] GoDaddy holding domains "hostage" via so-called "opt-in" procedures?

[George Kirikos <icann@xxxxxxxx>]

Hi Michael,

On Fri, Jun 18, 2010 at 9:58 AM, Michael Collins <mc@xxxxxxxxxxxxxxxxx> wrote:
> Welcome to the IRTP group. There has been much discussion about this issue.
> I understand the frustration. I have personally been inconvenienced by this
> policy. As usual, there is a delicate balance between security and
> convenience. One thing that came up in discussions is that hijackers will

Thanks for the welcome. I've read all the discussion, and I don't
think it's been deep enough, as I'll detail once the official comment
period opens up. But, consider this a "preview" (in addition to what
I've posted elsewhere, e.g. on DomainState). Please note you've
acknowledged that there is a "balance" (i.e. cost and benefit), as
I'll refer to this below.

> often make a registrant change immediately before an inter-registrar
> transfer. This leaves the hijacking victim without the ability to use TDRP
> or our proposed ETRP to recover a hijacked domain name because they are not
> the registrant at the time of the inter-registrar transfer.

Yes, some hijackers do this. But, a *lot* of legitimate registrants
also change the WHOIS before moving the domain name. Remember,
registrants have an ICANN-mandated obligation to keep WHOIS accurate
at all times. Recall:

http://www.icann.org/en/announcements/advisory-10may02.htm

"3.7.7.2 A Registered Name Holder's willful provision of inaccurate or
unreliable information, its willful failure promptly to update
information provided to Registrar, or its failure to respond for over
fifteen calendar days to inquiries by Registrar concerning the
accuracy of contact details associated with the Registered Name
Holder's registration shall constitute a material breach of the
Registered Name Holder-registrar contract and be a basis for
cancellation of the Registered Name registration."

Notice there's a 15 day time period there (and keep an eye on words
below). Note that GoDaddy even offers a "Domain Transfer Validation
System", see:

http://www.godaddy.com/iPhone/Legal.aspx?document=DOMAIN_TRANSFER

to lock-down the so-called "at risk" "very valuable" domain names
(notice that even refers to a 5 business day period). As does VeriSign
through it's Registry Lock service (and 2-factor authentication), see:

http://www.icann.org/en/registries/rsep/

(2009005 and 2009004) So, all the "high value" domains *can* be
protected, right now. Let's repeat that -- there's no excuse for high
value domains to be at risk anymore. MarkMonitor has blogged about
this:

http://www.circleid.com/posts/domain_registry_locking_why_not_use_it/

Notice the lines in the WHOIS about "server transfer prohibited",
"server delete prohibited", etc. That's the signal. So, for example,
Facebook.com is not going anywhere, as it's protected via that service
(at MarkMonitor):

http://reports.internic.net/cgi/whois?whois_nic=facebook.com&type=domain

Same for Google.com, Yahoo.com. Other registrars are able to offer
this. (I can privately send you a list of some of my domains, that are
protected. I obviously own a multi-million dollar portfolio of elite
domains and websites, as most of you know --- if anyone should be
concerned about protecting their domains from hijacking, it's me.)
*That's* where the emphasis should be. Indeed, go back and read the
recommendations for *2005* on hijackings, which appear to not have
been read by everyone in this group (as some appear to be
rediscovering the wheel):

http://www.icann.org/en/announcements/hijacking-report-12jul05.pdf

Every solution was spoonfed to the public 5 years ago, but the report
just sat there. I'll just pick out a couple for now (there were a lot
more, but I don't want to flood the group -- I'll save that for my
formal comments later -- I had 30 pages of notes that need to be
condensed).

"5)     Consider measures to improve authentication and authorization used
in all registrar business processes, but especially in these sensitive
change processes:
i)      change of delegation information, ii)
changeofcontactdetails(credentials), iii) change of registrant
(selling the name), and iv) change of registrar. (page 36)"

"ICANN should publish additional consumer information that explains
the domain transfers policy and processes, and identifies the areas of
risk for a registrant. ICANN could provide a list of questions a
registrant can ask a registrar to determine the level of
authentication and protection mechanisms used to manage domain names.
(page 38)"

It's bad enough that one major report was overlooked. But, it's worse.
Take a look at the report from August 2009:

http://www.icann.org/en/committees/security/sac040.pdf

where once again, the solutions are spoonfed to everyone:

Registration verification.  (page 14)
Improve password-based authentication system.  (page 15)
Multi-factor authentication. (page 15)
Multiple, unique points of contact. (page 16)
Change notifications or confirmations. (page 17)
Multi-recipient notifications (page 17)
Multiple delivery methods for critical correspondence. (page 18)
Periodically verify contacts. (page 18)
Finding (4) Registrar services (and registrants) place greater
confidence on the single factor authentication for login to accounts
than the method merits.  (page 22)
Finding (7) Registration service providers rely more heavily on
unconfirmed email to deliver security-related correspondence (e.g.,
change notifications) than email delivery assurance and security
characteristics merit.  (page 23)
Recommendation (1) Registrars are encouraged to offer stronger levels
of protection against domain name registration service exploitation or
misuse for customers who want or need them.  (page 24)

It's all there! It's hilarious I have to join this group to point it
out. IT'S ALL THERE!

> A 60-day lock increases the opportunity for the registrar or victim to
> discover a hijacking before the domain can be transferred away. Despite the

How? Why 60 days? Why not 5 business days (the GoDaddy contract), not
15 days (the RAA requirements?). What do people think is going to
miraculously happen during those 60 days? Indeed, why do people need
to "discover" this by a miracle, by magic, etc., when the means exists
to *proactively* involve them, when the change is made? Consider:

http://gnso.icann.org/meetings/transcript-irtp-b-pdp-13oct09-en.pdf

"If they need to transfer then they should do the transfer first and
then make the change at the new registrar." (page 24, Tim Ruiz)

"But what normally happens is if someone does complain and we’re able
to do some separate confirmation or whatever their situation were
where we’ll let the domain name go." (page 25, Tim Ruiz)

So, complaining lets you trigger the "separate confirmation". It
*begs* the question, why doesn't that separate confirmation take place
*before* the registrant change? It's such an obvious question, one
that was basically spoonfed in not 1 but 2 ICANN reports. Why? Plus,
if the name was valuable, it could have had that stronger lock, in any
case.

Or, basically you can avoid the 60 day "lock" by changing at the new
registrar. That's considered the "best practice". But, under the ETRP,
it could be clawed back? No way.

> potential inconvenience to registrants, I thought we should consider making
> the lock mandatory for all registrars. My desire is to reduce sales of
> hijacked domains and I thought this might help. The majority of the group
> prefer leaving this and other security measures up to the registrar.

Now, go back to the earlier point you attempted about the "delicate
balance." If your only metric is to "reduce sales of hijacked domains"
and think this "might help", you need to think again.

(1) reducing sales of hijacked domains is an unbalaced metric. You
need to talk about that "balance". You could reduce sales of hijacked
domains quite easily --- just eliminate sales of ALL domains. That
would also completely eliminate sales of hijacked domains, too. If
that's the success metric, you'd have achieved a perfect result. But,
it's obviously a result with many unintended consequences and with a
lot of collateral damage.

(2) It "might help" compared to what? There are many alternatives,
spoonfed from 5 years ago. I could give you my email address
passwords, and you'd not be able to hijack my protected domains. Why?
Because I've done my job to protect my domains. Why aren't more
registrars and registrants doing this? That's what this workgroup
should have focused on, i.e. the education, implementing the
recommendations from 5 years ago, etc.

(3) The half-baked ETRP. Here's where I saw red. Folks had 5 years
with the answers sitting in front of them, and they come up with this?
Sheesh. I could write for ages on the effects on the secondary market
of creating uncertainty over title to a domain for 6 months. But,
let's focus on the mechanics of the ETRP.

The "old registrant" is going to make some sort of claim through their
old registrar that the domain was hijacked, to start the process.
Presumably, the registrar has to validate that request. Hello? This
demonstrates it's *possible* for the old registrar to *validate* the
request, possible for them to validate the domain transfer, change of
registrant, etc. Why are they doing this "AFTER THE FACT", instead of
*PROACTIVELY*, before the domain name is transferred, change of
registrant, etc. Hello???

I'm going to stop here, because I hope by now I've demonstrated my
point. I'm against domain hijackings and have helped numerous
registrants recover their domains. This is not the solution, but is
worse than existing solutions, and leads to unintended consequences
and collateral damage far greater than the actual problem (i.e. we can
go over how many unresolved domain hijackings occur; the problem is
small, and there are other emergency solutions, e.g. going to the
courts). The "delicate balance" is destroyed by the ETRP. The
proactive solutions were discussed years ago, and are already being
implemented. Those are far superior, and raise security for everyone.

Michael and I share a lot in common in terms of wanting to protect
registrants, so I hope he'll withdraw his support for the current
report, and rethink the issue. Same for other members of this
workgroup. It'll  save me the trouble of writing a 50 page "minority
report" comment, and make the summer easier for everyone, rather than
spend 6 months doing an "oops" and having to pull a 180-degree turn
about this ETRP. Everyone I've talked to about it sees the problems
immediately that ETRP would cause. If folks go back to the basic
questions that they thought they answered, this group would be steered
in a proper direction, in my opinion. Folks should not get emotionally
attached or "invested" in the current report, as in my opinion it
leads much to be desired, and frankly I'll lose a lot of respect for
folks who continue to support it after they've had an opportunity to
think more deeply about what the report stands for.

Sincerely,

George Kirikos
416-588-0269
http://www.leap.com/

P.S. I'm free to talk to anyone by phone if they'd like. No one has
taken me up on that offer to date. I won't bite.....hard. ;-)