What rules have been used for the current list of codepoints?

[John C Klensin]

--On Tuesday, 26 December, 2006 15:55 +0900 Martin Duerst
<duerst at it.aoyama.ac.jp> wrote:

> [Most of this post was written a while ago, but I found
> out it wasn't sent when cleaning up.]
> 
> At 19:06 06/12/15, Gervase Markham wrote:
> 
>> The way to avoid spoofs is, instead, to cut down the set of
>> characters as far as is reasonably possible and then to
>> require registries to have policies which do not issue two
>> confusable domain names to different entities. There are
>> several technical and logistical ways of achieving this. I
>> see no reason why a registry would object to having a policy
>> which prevents some of its customers defrauding other of its
>> customers.
> 
> I agree.

Let me say this one final time.  If the motivation of the
registry is "service to the Internet" or "service to the users",
and they take one or the other (or both) seriously, then there
is no such reason.

However, if the motivation of the registry is either "make as
much money as possible by selling as many names as possible" or
"keep costs as low as possible", then the registry's incentives
and behavior are different:

(1) The possibility for confusion is a revenue opportunity,
manifested in advertising campaigns based on "you had better
register (and pay for) all of those possibly-confusing names --
it is lots cheaper than court or UDRP proceedings, much less
having to ransom your name from the pornographers or have your
reputation damaged by them".  Since we have already seen such
advertising campaigns in the LDH environment, it is reasonable
to expect that the same morals and tactics will apply as the
"opportunities" with IDNs become more obvious.     A
particularly unscrupulous registry might even form a quiet
partnership with a pornographer to make the threats more
meaningful. 

(2) All of the (fairly complex) "test for mixing of scripts with
exceptions and exclusions" rules that seem to be evolving are
going to require additional code paths.   A large registry
services a huge number of registration attempts a day and has no
way to recover costs associated with "tasting".  The costs of
those additional tests, no matter how small, are associated with
sufficiently large multipliers to take them straight to the
bottom line.  Unless compelled by morality or external
pressures, a registry has some incentive to _not_ implement any
rules of this type.


>> This is the policy that Firefox adopts; we currently display
>> IDN domain names for around 30 TLDs, the registries for all
>> of which have anti-spoofing policies. Any registry with such
>> a policy is welcome to ask to be included in the list, and we
>> will ship the list change in our next security update.
> 
> I don't like this, because it's technology policing policy, and
> it could be misused in all kinds of ways. It may put a heavy
> burden on browser makers: Is 'any policy' good enough? Checking
> the policy takes work. Where do you draw the line between good
> policies and 'not good enough' policies? Do you check not only
> for the existence of a policy, but also for actual
> implementation/ enforcement? If yes, how? If not, why not?
> What if a registry has a very good policy, but doesn't make
> every detail of it public? Why do you think you know, better
> than others, what the right policy is? Do you reserve the
> right to retract a TLD from the list even if their policy
> doesn't change, but you find out that it left some loophole
> open? And how long does it take to get a security update out,
> and how does the need for a security update negatively affect
> the deployment of IDNs?

You left out the rather difficult problem of "TLD registry that
behaves well by that permits spoofing-type names at the third or
fourth level because they see no way to prevent them".  I see no
way to prevent that one, but suggest that, as soon as a user who
"sees what they expect to see" encounters
omega-omega-omega.example.com, the "browsers can solve most
problems with these rules" theory is in deep trouble.

The issues of domain labels at the third level raises an
interesting problem that we can't solve.  A registry could, in
theory, adopt and enforce policies about the names its
registrants put in their subdomains and require that its
registrants enforce those rules recursively on their
registrants, is a TLD registry responsible.  Given that, can the
top-level registry be held responsible when spoofing occurs deep
in the tree and required, e.g., to terminate the second-level
registration?  Please note the interesting parallel between this
question and some of the arguments about spam control and ISP
responsibility a few years ago.

> These are just too many questions for me to think this is a
> good idea that browser creators make judgements about
> registration policies.

I continue to believe that there is no single place at which we
can apply a solution and have it cover all, or even most cases.
Our problem is seeing what can be done (technically and
appropriately) at the protocol level, what can be done in
registries, and what can be done in user interfaces to the
applications.  I believe that we are going to need a mixed
strategy, with some techniques applied at each level.  I do not
believe we are even close to getting the balance right or that
any perfect mix is possible.  In the long term, I hope that the
marketplace will help sort the issues out by punishing those
whose policies are sufficiently out of line with reality.
Conversely, in the short term, I fear that too-protective
policies and too-many warnings will render IDNs useless and
essentially kill them.

>> This is the mixed-script question, not the unfamiliar
>> character question. But, to use your example, if
>> payp<cyrillic-a>l.com gets issued to someone other than the
>> owner of paypal.com, then that is squarely the responsibility
>> of the .com registrar, and they should be taken to task for
>> it.
> 
> They have been 'taken to task' for it, and taken that offending
> URI off quickly. And I'm pretty sure they won't make the same
> mistake again.

But, under current rules, it is _not_ their responsibility.
They may decide it is a bad idea and prevent it.  They may
_voluntarily_ follow ICANN Guidelines to avoid this sort of
thing.  But their formal agreements with registrars tend to pass
responsibility for this sort of thing onto the registrars and,
through them, the registrants.  I haven't read recent versions
of the contracts between ICANN and the gTLD registries lately,
but I don't recall seeing any "we can make up whatever rules we
like and, if you don't follow them, we will shut down your
domain and you and your registries and registrants promise to
not sue us" clauses.  And I am certain those clauses are not
present in the ccTLD contracts, because those contracts
generally don't exist.

I might wish the world were different and, in particular, that
greed and stupidity had been stamped out.  But I think we need
to make our decisions based on the world as it is, with as few
utopian delusions as possible.

>> It should not need to be the user's responsibility to avoid
>> being taken in.
> 
> Well, yes, but ultimately, users have to learn that there are
> some dangers on the Internet, the same way visitors to the US
> (and most other countries) have to learn that there are some
> places you better don't go to.

And telling the users that one has protected them from all
dangers actually increases their risk level in practice.

     john