Re: nameprep, IDN spoofing and the registries

From: William Tan (
Date: Tue Feb 22 2005 - 07:06:33 CST

  • Next message: Mark E. Shoulson: "Re: Codepoint Differentiation"


    > As George points out, the registries are going to have to start
    > filtering IDN lookalikes, otherwise they will eventually face lawsuits
    > from the "big boys" (as George so delightfully puts it).

    Actually, I don't see that happening. It is generally accepted that
    neither gTLD registries or registrars check the names with human eyes
    before registering them. You can't sue if they've not been negligent.
    While I hope that gTLDs such as Verisign start filtering, I'm afraid we
    can't wait that long. That is why an application level solution is

    > The ccTLDs will have a relatively easy task, while the gTLDs like .com
    > will have the difficult task of deciding which subset of Unicode to
    > allow.

    Actually, most ccTLDs who are currently not offering a bundling solution
    specifically decided not to do bundling. They were fully aware that by
    not bundling, they are allowing the possibility of spoofing with the
    introduction of IDNs. And they have valid reasons for not doing so. This
    homograph attack advisory may well trigger some of them to change
    policies (though highly unlikely IMO), and hopefully get registries that
    are considering implementing IDN to employ some form of bundling
    solution, if applicable.

    > They will also have to go through their database, looking for
    > lookalikes, and deleting them or transferring them to new owners,
    > probably paying their previous owners back.

    If you're running a registry, you'd understand that deregistering or
    transferring a name against the registrant's will is no where as easy as
    it sounds. You might see lawsuits here.

    > One possible approach for the gTLDs is to halt IDN registration now.
    > Then they can work on their filters, starting with a small subset of
    > Unicode. After reopening IDN registration, they can grow the subset if
    > there is enough demand for characters outside the initial subset.
    Sounds like a logical solution to me, that's the easiest way to stop
    spoofed names from being registered. Again, it may or may not happen
    depending on the registries in question.

    > If the gTLDs are going to do some serious subsetting, then they will
    > probably also need to provide software to the registrars that will map
    > users' characters into the subset. E.g. converting a user's local
    > charset to the subset of Unicode. Then again, this might be an area
    > where registrars could compete with each other, to provide the most
    > friendly software to the end-user (registrant).
    It would really be nice if filtering is done earlier (i.e. at the
    registrar level instead of registry level) but that's not currently the
    case for Verisign's registrars, I suspect because it requires
    significantly more work for both the registry and registrars, not to
    mention that when the rules change, the registry needs to push the
    changes to the registrars.

    Right now, if you went to an ICANN accredited registrar and try to
    register an IDN, you'd need to input your unicode string, and select a
    language tag from a list, then click submit. The registrar does
    ToASCII(your_domain_name) and send the results along with the language
    tag to the registry after you have submitted your credit card details.
    Now, if the language tag you selected has a table attached, the registry
    will check the submitted domain against the table. At this point, if the
    test fails, an error will be returned to the registrar, then only do you
    get the message. And if you're lucky, at this point your credit card
    would be refunded.

    That might just be a particular registrar's implementation, but I did
    experience it. I don't know if Edmon's IDN-over-EPP is going to help
    with the situation, since I don't know what's going on in the SRS.


    This archive was generated by hypermail 2.1.5 : Tue Feb 22 2005 - 07:08:00 CST