Given the recent panix.com hijacking, I will give an outline of the
current ICANN transfers process for gtlds.
In the case of panix.com, evidence so far indicates that a third party
that holds an account with a reseller of Melbourne IT, fraudulently
initiated the transfer. The third party appears to have used stolen
credit cards to establish this account and pay for the transfer. That
reseller is analysing its logs and cooperating with law enforcement.
There was an error in the checking process prior to initiating the
transfer, and thus the transfer should never have been initiated. The
loophole that led to this error has been closed.
The transfer process has several checks and balances that are described
below. It seems that in this case none of these worked. I can only
comment on those from our end.
Note also that panix.com was held in the .com registry, that does not
use the new EPP protocol which incorporates the facility to store a
separate password (called auth_info) for each domain name that must be
checked before completing a transfer.
Problem - you are talking about changing registrar, but in reality you
describe changing of domain owner.
Why (what for) is it allowed to transfer from one registrar to another with
changing NS records and other owner information?
Why don't separate this 2 events - changing registrar, and changing domain
owner/information? Is it any need in reality changing registrar with
simultaneous changing domain information?
What should happen in normal situation:
- someone requested transfer of domain (without real authorisation);
- even if all checks pass and transfer was allowed, new registrar should
maintain the same NS and other information as old one, so no real damage
could happen;
- domain owner received e-mail, see frauded transfer and disputed it (having
domain in working condition on the new registrar);
- new registrar OR old registrar OR VeriSign roll back transaction.
Problem - you are talking about changing registrar, but in reality you
describe changing of domain owner.
conceptually, you are correct.
Why (what for) is it allowed to transfer from one registrar to another
with
changing NS records and other owner information?
Why don't separate this 2 events - changing registrar, and changing domain
owner/information? Is it any need in reality changing registrar with
simultaneous changing domain information?
yes, every day. a lot of people register their domain through their shared
hosting company, so when they decide to switch to a competitor, they switch
both. it is irrelevant whether the losing and gaining registrar reseller use
the same registrar, in this case.
Can you confirm or deny whether this actually happened in the case of
the panix.com transfer?
The other problem I see in this area is that the RRP specification (if
that is in fact the protocol that was used) seems to claim that this
message is out-of-band and thus beyond the scope of the protocol: so it
does not (can not) specify an ACK. If an attacker found a way to prevent
this message from being received, even if generated...
A strictly enforced technical requirement for an ACK here might work
wonders (perhaps it would have to be enforced by duping both the
confirmation and the ACK to the "System", as RRP so quaintly calls it, and
denying future transfers initiated by parties with too many outstanding
ACKs). Not an approval, just an ACK.
There seems to be a general lack of IETF design and review of protocols
in this crucial area. Again not good.
Possible there is some confusion here. While there is an informational
RFC describing RRP, it clearly says:
VeriSign Registry Registrar Protocol (RRP) Version 2.0.0
and
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
The work in the IETF has been on EPP, and it was done in the usual
IETF open working group; it is currently at proposed standard.
There is some discussion of taking it Draft Standard at this point,
and if you know of problems with EPP that mean it should
be changed and re-cycle at proposed, now would be a good time
to bring them up. The original working group mailing list,
ietf-provreg@cafax.se, is still open for discussions of this
kind.
regards,
Ted Hardie
There seems to be a general lack of IETF design and review of protocols
in this crucial area. Again not good.
Assuming "this crucial area" to mean registration protocols, including EPP, IRIS, and DNS, I'd say that there is ample opportunity for review, although what is done is still insufficient. (It will always be "insufficient" to some.)
The IETG Working Group's for these protocols are -
WhoIs and RRP are not related to WG's so far as I can recall.
These web pages mention mailing lists for the groups. That is how to provide "design and review" without the expense of travel.
I know all about insufficient design and review. I've seen DNSSEC overhauled when the initial review process failed. As co-chair for PROVREG, trying to get wider review was the main job. (Early on, no one wanted to hear about it...)
PS - If you can contribute "client-side" expertise to many of these protocols, you will be in high-demand.