[Resent to the list from two days ago because I never saw my original
post appear; apologies if other people see this twice.]
At 9/15/00 4:37 AM, Charles Daminato wrote:
>It may appear to have a weak point, but consider this scenario. A party
>initiates a transfer request, THEN manages to get NSI to alter their whois
>(or which ever other Registrar it is). They convince the RSP to resend
>the email and it goes to the new address. The original Admin in this
>transaction may have not had time to act before this all takes place, and
>subsequently loses his domain name - but still has a valid transfer email
>which SHOULD allow him to allow/cancel the transfer request.
Thanks for the reply!
Maybe I'm being dense, but I don't see that as a problem. In this
situation, OpenSRS would have sent a later confirmation to the current
admin contact address, and received approval from that address.
OpenSRS would indeed have ignored the wishes of the old admin contact,
but surely that's irrelevant (and perhaps even the Right Thing to do) --
why should the admin contact from two days ago get any say in it? We
don't worry about this situation if the admin contact changes two days
before the original transfer request was submitted, so why worry about it
if it changes while the transfer request happens to be pending?
I guess I'm saying the current system doesn't actually add any real
protection against domain hijacking. If a malicious person successfully
changes the domain's contact address while there's an outstanding
transfer request, but doesn't get a confirmation message, he could simply
resubmit the request after the first one failed. (Or he could submit
another transfer request at a different registrar right away.) Then he
would get the message and transfer the domain anyway.
All the current system does is delay the malicious transfer a few days in
the worst case -- and it only achieves that by delaying *all* failed
transfers by a few days.
>The only way we can allow a cancellation while waiting for the domain
>owner is to have the domain owner cancel the transfer. Somewhat of a
>catch-22, I agree. But if you think that if there is *one* transfer that
>is awry, someone complains sufficiently to ICANN, OpenSRS can lose its
>accreditation (this applies to ALL Registrars...).
Hmmm. The problem would have occurred at the old registrar, where someone
unauthorized was able to change the contact address; surely OpenSRS
wouldn't be at fault for simply using the current admin contact as
authoritative. Again, we're giving the old admin contact more power than
the current admin contact, and we're worrying about a case that we
wouldn't even notice if the malicious person changed the contact address
immediately before submitting the transfer request (as a smart malicious
person would do anyway).
To sum up, I appreciate the consideration given to security, but I think
this policy of not trusting admin contact address changes while a
transfer request is pending is misguided. It inconveniences a lot of
people (changing the address to be able to receive transfer requests is a
common legitimate thing to do) in an attempt to shield OpenSRS from
getting publicly blamed for something that wouldn't be your fault anyway,
and it doesn't actually prevent malicious behavior other than by causing
malicious people to experience the same inconvenient delay legitimate
people experience.
Because of that, I'd like to respectfully suggest that either the current
(possibly updated) address be used when resending the transfer
confirmation messages, or that the RSP be allowed to cancel the first
transfer request and send a new one immediately.
Thanks for listening -- I know I'm sounding like a broken record about
this, but I'm tired of telling customers "the problem with your admin
contact is now solved, but we'll have to wait a week before we can try to
transfer the domain again". We've cut down on the problem by trying to
manually check the addresses first, but some still slip through, and it
would be wonderful to be able to just try them and only worry about
fixing the ones that fail.
--
Robert L Mathews, Tiger Technologies
