[idn] who should be doing IDN filtering

[Eric Johanson <ericj@shmoo.com>]

I've been lurking on this list for the past few days - - and it seems that 
we've been thrashing about with different filtering techniques IDN on 
various TLD/registrars, etc.  I hope this post won't prove to be a 
distraction from that dialog (as I'm one of those "don't know anything 
about unicode" folks).

My question for the group:

Are you sure that it's the registrars/TLDs/etc whom should be doing this 
filtering?

I understand that that by using the language tag, it generally might make 
some type of filtering concepts easier & more practical to deploy.

Because this 'language tag' is only available to registrars (when I say 
registrars, I mean anyone involved with the registration of a new domain, 
on any TLD), I suspect it makes it impractical to do the filtering at the 
browser/application level.

My question is:

...assuming we can make the language tag available via some dns tricks or 
some API...

Shouldn't we leave the filtering up to the user, and the user's browser? 
It's likely the application will know more about what the user expects as 
far as site identity (some tricks I've heard proposed is to not warn about 
sites in the users favorites, or create whitelists of 'trusted sites' [see 
trustbar]), and knows about the local language settings.

For example, if I have windows XP, with the default language set to 
german, the browser isn't (as obligated) to warn the user of potential IDN 
phishing attacks when it sees german scripts in the IDN. My hope is that 
this idea could scale to any script/language, but I fear that I'm missing 
something.

I'm not proposing we don't have some type of filtering of IDNs at the 
registrars, etc.  I'm simply proposing we give application (browser, 
email) developers the same information the registrars have, in order to 
give them a fighting chance of warning the user of a homograph attack.

Taking this one step further:

.. if we think about IDN homograph attacks as the same class of problem as 
'spam/UCE'....

..Then tools will just start to exist to filter it. Imagine, if you will, 
a RBL which collects IDNs found in spam/phishing attacks, and communicates 
with a users browser.

Comments/ideas/flames?

-Eric 'Dodgy Character' Johanson