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.