Subject: RE: [idn] homograph attacks

From: "Michel Suignard" <[email-masked]>
Date: Tue, 15 Feb 2005 22:12:21 -0800

No languages used in the former soviet union should require a mix of latin and cyrillic in a single dns label.
Unicode contains many latin homographs in the Cyrillic block exactly for that reason, to avoid mixing the two scripts in a single word. It is unfortunate that the exact visual match is now haunting us. However it should not be used as a rationale to accept registration of mixed Cyrillic/Latin labels by tld registries.

To answer another message in this thread, there is no definitive answer about which Unicode characters are allowed for a given languages. But in all languages that have a reasonable concept of 'words', you should never need to allow mixed script in a word, at least in the context of IDN label. There are exceptions to these rules, like in South and East Asia (Japanese comes to mind), but these languages can be detected reasonably using the Unicode script property.

Michel 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kane, Pat

VeriSign does prevent domains with the Russian language tag from commingling A-Z with the Cyrillic characters.  It does permit 0-9 and the dash to be used.  This filter also applies to other Cyrillic based languages such as Belarusian, Ukrainian, Serbian, Macedonian and Bulgarian.  

There are other languages that are listed within ISO 639-2 that today use a combination of Latin and Cyrillic as they were originally Latin based (Tajik was Arabic prior to being Latin based), migrated to Cyrillic during the Soviet era and today are migrating back to Latin.  It is common to use Latin and Cyrillic characters in Tajik, from what I understand not being a native speaker.  Granted there are not a lot of registrations in com net that are Tajik, but this is just the point of an IDN.

Pat Kane

---

From: "Martin v. Löwis" <[email-masked]>
Date: Wed, 16 Feb 2005 07:59:16 +0100

Michel Suignard wrote:
> To answer another message in this thread, there is no definitive
> answer about which Unicode characters are allowed for a given
> languages.

There is no definitive answer to that question. However, I sure
hope there is a definitive answer to the question "which Unicode
characters are allowed for a given language" *when used as
a label in the .COM zone*. For another example, the definitive list
of (additional) characters for a German label in the .DE zone is

http://www.denic.de/de/domains/idns/liste.html

On the other hand, a German label in the .CH zone is

http://www.switch.ch/de/id/faq/idn.html

which is a subset of the .DE list. I'm (now) certain that Verisign
has a definitive list of characters for a German label in the
.COM zone (and I expect this is the same list that DENIC uses,
as that is the superset of the Austrian and Swiss sets).

Regards,
Martin

---

From: Thomas Keller <[email-masked]>
Date: Wed, 16 Feb 2005 10:44:24 +0100

I'm by no means a linguist but I would assume that there are a plethora
of good and usefull mixtures of scripts that exist in daily life. Passing 
this problem (of which all of us have been aware of for years now) back 
to the policy arena won't help anyone since I doubt that there can be any 
kind working group (now or in the future) that can come up with a good 
rational for all scripts and languages without restricting "good" and usefull 
mixtures. 

By design the IDNA processing happens inside the application and therefore in 
my thinking the applications are the right place for any security meassures 
as well. Talking about about security measures we have to think about what
exactly we want to prevent from happening. Do we in general want to battle 
fraud than we would have to have a look at typo domain names like pajpal.com 
as well or is the goal to enable the user to better understand exactly what URL 
he is using. In that case we are not talking about security anymore but about 
awareness. If a user is aware of the fact that a URL he wants to use is a
mixture of scripts he can decide for himself whether he wants to trust it or not. 
I guess thats fair enough afterall are all users responsible for there own behavior 
and the risks comming along with it.

Best,

tom

> There are other languages that are listed within ISO 639-2 that today use a combination of Latin and Cyrillic as they were originally Latin based (Tajik was Arabic prior to being Latin based), migr…

Gruss,

tom

(__)        
(OO)_____  
(oo)    /|\	A cow is not entirely full of
  | |--/ | *    milk some of it is hamburger!
  w w w  w

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 16 Feb 2005 12:04:30 +0100

I will try to review some of the points with an intergovernance consistency 
in mind (what we want the user to get the same service whatever the Registry).

>and cyrillic in a single dns label.

Recent Ukrainian comments on [email-masked] (the reference 
list for language tags) said they are back to roman characters, so I 
suppose there are mixed TMs which need a mix. This shows the WIPO should be 
part of the debate.

>To answer another message in this thread, there is no definitive answer 
>about which Unicode characters are allowed for a given languages.

In a domain name, yes: the IANA Table by the ccTLD Manager. In an IRI DN 
part this should be the same.
Beware, these are just ICANN recommendations to sovereign entities. What we 
should agree upon is that when there is a mix, the user could be warned a 
way or another.

>But in all languages that have a reasonable concept of 'words', you should 
>never need to allow mixed script in a word, at least in the context of IDN 
>label. There are exceptions to these rules, like in South and East Asia 
>(Japanese comes to mind), but these languages can be detected reasonably 
>using the Unicode script property.

As discussed above, this is debatable. But the mere fact that you accept an 
exception create the need to support what happens in such cases.

At 07:50 16/02/2005, Martin v. Löwis wrote:
>I don't speak for Verisign, but I can answer some of the questions:

You comment them. My questions to Pat Kane remain.

>>1. where do you maintain an ASCII list of your language tags?
>
>It is *maintained* probably on some development infrastructure inside
>Verisign, it is published atleast at
>
>http://www.verisign.com/static/002533.pdf

PDF is hardly an ASCII list.

>>Should it not be supported on the IANA server and common to all the gTLDs?
>
>I personally don't see why it should be on a IANA server.
>As for "should it be common to all the gTLDs", I honestly believe
>the answer should be "no".

These opinions of yours are opposed by gTLD contracts with ICANN.
There is a IANA registration for IDN Table, even very poor.
The proposed "RFC 3066bis" Draft lead to a debate where the authors
who are discussing the language tags to be registered by IANA
described as outrageous the idea that they should consider IDNs
and be consistent with them. Do you support that?

>>3. did you decide them by yourself, or did you gather a group of lingual 
>>authorities to assist you. This would be very interesting.
>
>While working to address the issue of character variants, VeriSign has 
>consulted and will continue to work with all interested stakeholders.

We co-created Eurolinc with Louis Pouzin and some others. We are members of 
the ccTLD WG-IDN. Never been consulted by VRSN.

>>4. would there not be a way to register IDN in using their  "xn--" 
>>version? It would simplify international management by resellers?
>
>Why do you think the SRS currently does not use the xn-- version in
>registrations?

??? I just say I want to be able to register the name in entering its ASCII 
xn-- string.

On 10:44 16/02/2005, Thomas Keller said:
>exactly we want to prevent from happening.

Incorrect. "Application" as in a browser etc. is a wrong idea and will 
probably never fly. Application can realistically be understood as an 
application to the path. This is the OPES concept. Has been documented for 
HTTP and is on the (slow) work for SMTP. However IRI consistency/analysis 
could be of interest, should the IRI specs. permit it.

> > There are other languages that are listed within ISO 639-2 that today 
> use a combination of Latin and Cyrillic as they were originally Latin 
> based (Tajik was Arabic prior to being Latin based), migrated to Cyrillic 
> during the Soviet era and today are migrating back to Latin.  It is 
> common to use Latin and Cyrillic characters in Tajik, from what I 
> understand not being a native speaker.  Granted there are not a lot of 
> registrations in com net that are Tajik, but this is just the point of an IDN.

This is the basic problem of the hybrid two keyboards IDN.ASCII domain 
names. The character set should be indicated by the TLD own character set 
and registered table. The resulting security violations come from ICANN. 
The mixed Tajik table is legitimate for Tajik people, not for others.

Let understand that naming is going to be as spam: a need for technical and 
legal cooperation to protect users.

On 07:59 16/02/2005, Martin v. Löwis said:
>There is no definitive answer to that question.

There is an attempt to a confused that we are to fight which is Draft 
3066bis defining languages tags.

>However, I sure

There is a IANA section for that to gather such Tables.

All what this shows is that there is a need for users to discuss technical 
issues and propose BCPs. This is not an uncommon problem so it might be 
worth proposing the IADs a WG-USERS? The WG-IDN charter proposed by James 
Seng initially included a market study. All this would have been part of 
the IESG approved/IAB reviewed charter of the WG-IDN. But the market would 
have most probably opposed the IDN.ASCII strategy.

jfc

---

From: William Tan <[email-masked]>
Date: Wed, 16 Feb 2005 21:22:00 +0800

> as that is the superset of the Austrian and Swiss sets).
Pat can correct me if I'm wrong, but my understanding is that VGRS does 
NOT have a table associated with the German language. So, if you went 
ahead and register an IDN, and selected the German language, you can 
pretty much register any label that is permitted by IDNA, including 
characters that aren't remotely related to German.

Regsards,
wil.

---

From: "Martin v. Löwis" <[email-masked]>
Date: Wed, 16 Feb 2005 20:36:46 +0100

> rational for all scripts and languages without restricting "good" and usefull 

Right. So what the working groups do is to come up with a good rationale
for all scripts and languages that *do* restrict "good" and useful
mixtures. I find no problems in that restrictions: it is better to be
restrictive now and permissive later than the other way 'round.

> as well.

Not only. Right from the beginning, the idea was to enforce policy in
the registry.

> Talking about about security measures we have to think about what

In the specific case, I think paypal.com with a Cyrillic "a" should
have been prevented from becoming registered.

Regards,
Martin

---

From: "Martin v. Löwis" <[email-masked]>
Date: Wed, 16 Feb 2005 20:51:59 +0100

> PDF is hardly an ASCII list.

Well, it contains only characters from the ASCII charset.

> These opinions of yours are opposed by gTLD contracts with ICANN.

Does that apply to the "old" gTLDs as well?

> and be consistent with them. Do you support that?

I don't think consistency across gTLDs is necessary (nor do I
think consistency across ccTLDs of countries using the same
"scripts" is necessary). What does matter is that the policies
are published and open for discussion. It is ok that the policies
evolve over time, in which case "legacy" registration need to
be considered.

Regards,
Martin

---

From: John C Klensin <[email-masked]>
Date: Wed, 16 Feb 2005 15:04:16 -0500

--On Wednesday, 16 February, 2005 20:51 +0100 "\"Martin v.
Löwis\"" <[email-masked]> wrote:

>...
>>> As for "should it be common to all the gTLDs", I honestly
>>> believe the answer should be "no".
>> 

Actually, this is just confusion at best.   The current ICANN
guidelines (and gTLD contracts to the extent they are relevant)
do not require at all gTLDs use the same tables for a given
language, nor that they register the tables they are using.  The
latter is merely a strong recommendation.

>> The proposed "RFC 3066bis" Draft lead to a debate where the
>> authors who are discussing the language tags to be registered
>> by IANA described as outrageous the idea that they should
>> consider IDNs and be consistent with them. Do you support
>> that?
> 

That view is consistent with current ICANN policy although, IMO,
the current requirements for publication and openness are
probably not yet strong enough.  It is not clear to me whether
or not ICANN would meet resistance if they tried to strengthen
those requirements.

regards,
   john

---

From: Erik van der Poel <[email-masked]>
Date: Wed, 16 Feb 2005 13:20:22 -0800

Hello all,

It seems to me that a registry should not allow the registration of an 
IDN domain name under a particular language if that registry does not 
have a table for that language.

When a registry *does* have a table for a particular language, the IDN 
domain name is restricted to the characters that appear in that table.

So, when there is *no* table for a language, then *no* characters should 
be allowed. In other words, no IDN domain names (starting with xn--) 
should be allowed.

Also, it seems to me that registries like COM could "stop the bleeding" 
(for now) by immediately deploying systems that enforce a policy where 
registrations for languages for which they do not have tables are rejected.

After that, they could continue to gather or compile tables.

Regards,

Erik van der Poel

---

From: "Martin v. Löwis" <[email-masked]>
Date: Wed, 16 Feb 2005 22:34:07 +0100

> have a table for that language.

I strongly agree. It is fine that Verisign was employing a IDN testbed,
and people have learned a lot of technology from that. But now, in the
operational phase, registrars need to be really careful, and err on the
side of restrictiveness as opposed to openess. If people find the rules
too restrictive, there is always the possibility to weaken the rules.

> After that, they could continue to gather or compile tables.

Precisely so. IDN is driven by market needs. So if there is a strong
need for registering, say, Tajik labels in .com, Tajik users will work
with national bodies to establish a language filter for Tajik that
gTLD registrars can use.

At the moment, it looks like the missing tables can be used for phishing
*only* - something I doubt is in the commercial interest of a gTLD
registrar.

Regards,
Martin

---

From: Erik van der Poel <[email-masked]>
Date: Wed, 16 Feb 2005 17:00:32 -0800

Perhaps "immediately" was too strong a word, and arrogant. My apologies. 
Any such changes should be carefully considered of course.

Erik

---

From: Erik van der Poel <[email-masked]>
Date: Thu, 17 Feb 2005 09:46:50 -0800

This does not make sense to me. As the title "Guidelines" suggests, they 
are merely guidelines for the registries to follow. They are not bound 
to those rules.

Just because ICANN cannot force the registries to follow this guideline 
does not mean you should just throw the baby out with the bath water and 
omit a guideline regarding missing character inclusion tables.

In networking, it is often better to be conservative. ICANN ought to 
know this.

Also, it would be really nice at this point to hear from, say, VeriSign, 
that they are seriously considering this issue. We haven't heard from 
them yet, but they are on this mailing list.

Erik

James Seng wrote:
> I think this suggestion was discussed in the IDN Committee that made the 
> proposed IDN Guideline but was shot down eventually for being too 
> restrictive to registries.
> 
> On 17-Feb-05, at AM 05:20, Erik van der Poel wrote:
>>