Re: [Re: [Re: [Re: [Re: [ga] Re: Transfers: Apparent AuthorityDiscussion]]]]

[Loren Stocker <loren@800.net>]

Hi Ross,

Thanks for you thoughtful comments, but I did put "forward a plan." See,
www.evil.biz for:

Page One: Introduction
Page Two: The Problem (WLS)
Page Three: The Solution
Page Four: The Comedy (WLS)

In my view you can't define the details until you understand the root cause,
in this discussion "one-party consent" transfers. But the bigger picture is to
define Subscriber Rights. We all know we have them, but nobody really knows
what they are! They must be defined. When you state....

"Registrars acting on what they "think" have not sufficiently fulfilled the
terms of their contract with ICANN. If we want to turn the discussion to what
are the means and scope of enforcement necessary to carry out *any* of these
proposals, then I am all ears ;)"

....You're speaking as a Bureaucrat. Who cares about the contract, ICANN, or
enforcement when MY domain is stolen? In my metaphor, it's like I'm on death
row and you're speaking about due process. Who care about due process when I'm
innocent! 

A one-party consent system can NEVER be safe. A domain Lock forces two-party
consent on a transfer but with the added hassle of a manual un-lock. Fix the
system -- make it two-party consent -- and the locks will serve as an optional
safe guard, not as the Registrants only way to safeguard domains in the midst
of a flawed policy.

I'll give you the last word.

Best, Loren


"Ross Wm. Rader" <ross@tucows.com> wrote:
>
> Good comments, Grasshopper. This is "research," I believe.
>

Only insofar as it seems to be indicitative of how much we know about what
we are doing ;)

> Ross, your comments and mine from a different point of view. I'm a
vulnerable
> Registrant and you an eager-to-grow Registrar. We both have good ideas but
> where I want FAILSAFE you want EASY transfers.

I'd characterize that more as a "once-bitten registrant" and a "weary
registrar that has spent more than a year exploring the problem space".

My biggest problem with the current discussion is that they do not have the
benefit of an attendant proposal. It is very easy for me to disagree or
agree with the specific points that you bring forward, but the devil is in
the details - the implementation, best processes, enforcement, remediation,
etc. Perhaps there is a better mechanism than the IRDX, but I have yet to
see it largely due to the fact that *no one* has taken the time to properly
explore their "ideas" and put forward a "plan".

More interspersed below...


>
> You make a dangerous assumption when you say the, "Gaining registrar is a
> representative of the registrant." How can you really know this?

Gaining registrar has an obligation to obtain and demonstrate this. The
Gaining registrar has a contract with this party, etc. For every hijacking
brought about by poor registrar processes, I can show you 10,000 examples
where the Gaining registrar was indeed representative and bound by contract
to the registrant.

> This is the
> essence of the problem and the 80/20 fix. What you are really supporting
is
> one-party consent with NO fail-safes. What good are published guidelines
when
> mistakes lead to disasters?
>

The fail safes are there - both proactive and reactive in nature.

> Having the losing Registrar validate is essentially a double check, or a
> two-party consent model. Inherently, the gaining Registrar validates that
they
> are working with who they think is the Registrant, or they wouldn't
process
> the transfer. Do you agree? The motivation is that they want to remain
> accredited, so they play by the rules.
>
> Then, under my proposal, the losing Registrar agrees to the domain being
> released.

Under the IRDX, the Gaining Registrar requests this approval from the
registrant via data recevied from the losing registrar.

> Of course they check with me. And they don't get to vote! This is
> Two-party consent. It also has a failsafe in that the losing Registrar,
KNOWN
> to be my agent, has a duty to me. I can also ensure that I have legal
recourse
> -- domestic legal recourse -- when I use Bulk Register as my Registrar as
I
> did in this recent fraud (I use and love Tucows too!).
>
> Under the absurd system of today, Registrars have the ungodly powers to
take
> my domain when they THINK they represent the real Registrant. You must
> understand that makes me vulnerable to theft from anywhere on Earth
> -- most of which I have no practical legal recourse!

Registrars acting on what they "think" have not sufficiently fulfilled the
terms of their contract with ICANN. If we want to turn the discussion to
what are the means and scope of enforcement necessary to carry out *any* of
these proposals, then I am all ears ;)

>
> I do not believe that a confirmation e-mail from Verisign is "unintended
> benefit." It is partly due to rampant fraud that they too have had to deal
> with. NSI created two-party consent within the insane system in place
today.
> What's the big deal with confirming a transfer? If I get peace of mind,
it's
> worth it. Why make this safe-guard into an "anti-competitive" villain?
>

There is no evidence of "rampant" fraud. For instance, I personally called
each of the registrants that Verisign claimed last year that "had no
knowledge that their registration had been transferred from VRSN to Tucows".
You know what? Every single one of them that I managed to contact were
indeed aware of who their current registrar (us) was. That's not to say that
mistakes won't happen from time to time. But, that's also not to say that we
should design a system around these mistakes. Rather, we need processes and
policy in place that allows us to pick ourselves up after the mistake is
made, fix the error and move on with as little impact as possible. Under the
current system, this is *not* possible.

> In fact, the real problem here is that bulk transfers -- which I do each
month
> -- lead to dozens of individual confirmations. It's not the confirmation
but
> the inconvenience of the confirmation that I have an issue with. Also the
> speed and accuracy. It seems to take a week or so between submission and
> confirmation. I always confirm twice, because it seems 10% of the
> confirmations get lost. This process can be mandated to be efficient and
safe.
> Within the SMS/800, for example, toll-free numbers are transfer within 48
> hours, given a clean request.
>
> Incidentally, Tucows's does not provide "transfer-away" notice by default.
I
> was walked through the step-by-step procedure to set up "transfer away,"
as
> noted in the e-mail I sent Ross off-list. Bulk for sure didn't provide any
> notice. My domain simply vanished.

Both of the circumstances that you mention are registrar specific
implementations. In the case of our practices, as you are aware, we try to
accomodate as many reseller models as possible - hence a ton of our services
are configurable.

>
> Keep in mind that one-party consent and "notice" are not as safe as
two-party
> consent. It's an improvement, but not as safe. "Locks" are in most cases
> overkill, and inhibit transfer by requiring manual unlocking (see "Domain
Lock
> Downside" on the Opensrs discussion list, today 01:05 PM PDT, 05/27/2002).
>

Locks are no where near as onerous as that thread indicated. The fact is
that it is only the registry-specific information that is locked. All of the
contact information is not. The fact of the matter is that all security
involves trade-off. In this case, you are forgoing the capability to easily
modify your nameservers in exchange for guaranteeing that no one can
transfer your name until you unlock it. Not a bad deal in my books.

<snip>

> Baby-steps are not what's needed here. It is the health of the forest --
not
> the few sick trees we've happened to notice -- that's at stake!

Comprehensive proposals that effectively spell out a solution are what is
needed here.

Thanks again for the time Loren - it is indeed nice to have a substantial
discussion of the issue with someone (finally ;)

Regards,

-rwr





--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html