[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[idn] Re: nameprep, IDN spoofing and the registries



Hi,

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 necessary.


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.

wil.