Subject: RE: [idn] homograph attacks

From: "Michel Suignard" <[email-masked]>
Date: Wed, 16 Feb 2005 17:35:31 -0800

Martin,
I don't think we are so far off. My concern is that many people are abusing the term 'language' for these tables. I am just saying that creating exclusive subset of Latin characters in European context is not necessarily a bad idea but will result in future problems because they will always discover that few characters are missing from the subset.

It is reasonably easy for .de to establish a table as they did and again it is ok. It is much more challenging for a worlwide TLD such as .com to establish registration rules. Typically script is a much better selector than language to establish those tables and associated rules.

And I was not talking about typesetting, thank you. Although it does not hurt to have some background in worldwide character set encoding. 

Michel

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 17 Feb 2005 03:16:11 +0100

At 02:35 17/02/2005, Michel Suignard wrote:
>Martin,
>I don't think we are so far off. My concern is that many people are 
>abusing the term 'language' for these tables.

Dear Michel,
you are absolutely right. The problem is the content of the tag and the term.

- IANA TLD Tables are described by language/script/ccTLD from ISO 3166 alpha-2
- languages are defined from ISO 639
- RFC 3066 appointed [email-masked] advisory mailing list 
Members have introduced a "langtag" which also concatenates the same 
content:  language (ISO 639) - Script ISO 15924 - Country (ISO 3166 - 
therefore missing some ccTLDs). The idea is to document the real language 
being used with some more accuracy.

The term that ISO 639 corresponds to "langues" in French and the proposed 
langtag to "langage" in French, and what they really need to permit 
automated interintelligibility would be "parler" in French. This might lead 
to complex and unnecessary debates. This is why we have adopted the 
following wording:

- langtag for a tag including lingual oriented information. We do not speak 
of language but of tag. Whatever the use.
- lang3tag is internationalization with language/script/localization 
(localization should be far more complete than just ISO 3066)
- lang4tag adds the authoritative reference for the used form of that 
language (multilingualization)
- lang5tag adds the style to document the vernacular environment of usage.

>I am just saying that creating exclusive subset of Latin characters in 
>European context is not necessarily a bad idea but will result in future 
>problems because they will always discover that few characters are missing 
>from the subset.
>
>It is reasonably easy for .de to establish a table as they did and again 
>it is ok. It is much more challenging for a worlwide TLD such as .com to 
>establish registration rules. Typically script is a much better selector 
>than language to establish those tables and associated rules.

This has been extensively discussed by the authors of the proposed "RFC 
3066 bis" Draft. I disagreed enough with only small but key details, to be 
credible I think when I say that I fully agree with their need of ISO 639 
to define the language (7260 in the current revision), but also the script 
(you are right this is necessary, but this is not enough for many reasons 
you described in part) and localization which may change some accepted 
usages. They identified that the political boarders were the leading 
descriptor here due to legal obligations, common education, etc.

Scripts defined by ISO are also disputed. Better to have an authoritative 
decision of the TLD Manager as a part of his namespace rules. After all 
what we want is "normality", so there are cultural, legal, IPR related 
matters to consider. I understand that M$ has decided to wait and see the 
way the market reacts. This time I approve M$.
jfc

---

From: Erik van der Poel <[email-masked]>
Date: Wed, 16 Feb 2005 21:06:46 -0800

Michel Suignard wrote:
> It is much more challenging for a worlwide TLD such as .com to
> establish registration rules.  Typically script is a much better
> selector than language to establish those tables and associated
> rules.

"Typically"? You make it sound like you've "been there, done that". :-)

Seriously, would you please elaborate on your ideas for .com? I would 
really like to know what you have in mind, specifically, to combat the 
homograph problem.

Thanks,

Erik

---

From: Martin Duerst <[email-masked]>
Date: Thu, 17 Feb 2005 17:55:28 +0900

Hello Eric,

I can't answer fro Michel. But I just had a look at the ICANN guidelines,
and they use the word 'language' 19 times (hope I counted correctly),
and the word 'script' not a single time.

However, there are at least as much 'script' aspects as there are
'language' aspects in the current problem, and if you look at actual
implementation in ccTLD registries that have deployed IDNs, it's
also quite a bit about 'script'. As an example, .ch has published
a single table although they are very clearly working with three
or four languages.

Too much emphasis on 'language' rather than 'script' also has lead
to strange claims such as that creating IDN TLDs is impossible
because we cannot create 6000 versions of .com. Again, looking
at this as a script problem is much more appropriate, after
all, neither "com" nor any ccTLD nor most of the gTLDs are
associated with any single language.

Regards,    Martin.

---

From: Martin Duerst <[email-masked]>
Date: Thu, 17 Feb 2005 21:39:29 +0900

Hello James,

If using 'language' only, and never mentioning 'script',
is by design, then would you mind pointing me to that
design, or explaining it to me?

Regards,    Martin.

At 19:05 05/02/17, James Seng wrote:
 >the choice of words of using language (instead of script) in ICANN 
community is by design.
 >
 >james
 >
 >On 17-Feb-05, at PM 04:55, Martin Duerst wrote:
 >

---

From: William Tan <[email-masked]>
Date: Fri, 18 Feb 2005 01:36:37 +1100

Hi Michel,

>I don't think we are so far off. My concern is that many people are abusing the term 'language' for these tables. I am just saying that creating exclusive subset of Latin characters in European cont…
I do not think that a few characters being missing from a particular 
version of a language table is that big a deal. After all, characters 
are still being added to Unicode. If the registry finds that there is a 
real demand for the missing characters, it can decide to revise the 
table with those characters included with little effort (as compared to 
shrinking a table.)

>It is reasonably easy for .de to establish a table as they did and again it is ok. It is much more challenging for a worlwide TLD such as .com to establish registration rules. 
>
Agreed. However, I think it is a worthwhile effort for a combined effort 
among gTLDs and relevant language experts to develop language tables 
that are appropriate for use in a gTLD context, and can be shared by 
other registries. In some cases, it may not be so difficult as ccTLDs 
that share a common language with each other often work together while 
establishing the set of characters to be allowed in their own IDN 
rollouts (eg. .at/.ch/.de for German and .ca/.ch/.fr for French).

>Typically script is a much better selector than language to establish those tables and associated rules.
>  
>
A script is a very convenient selector for publishing tables and in 
other applications such as localization. I don't agree that it applies 
"typically", although in some cases it does work quite well (.museum and 
.pl are fine examples.)

Even among the 92 characters that DENIC allows, which are all characters 
from the Latin script, as Roozbeh pointed out in the last ICANN IDN 
workshop that there is a visual resemblance between U+00D0 (the capital 
version of U+00F0) and U+0110 (capital version of U+0111). This would be 
an intra-script conflict (though the characters belong to different code 
blocks), and compared to the IDN-posing-as-ASCII-domain attack it is 
arguably less urgent. This serves to illustrate the importance of 
restricting the characters to the smallest practicable subset in IDN 
implementations. For a gTLD, the language tag comes in handy, so we 
could apply different language tables to IDNs according to their 
intended language. And using a conservative subset of characters for 
each language table is part of the deal, in order to reduce the 
possibilities of phishing attack.

Best regards,
wil.

---

From: Erik van der Poel <[email-masked]>
Date: Thu, 17 Feb 2005 08:00:25 -0800

Martin Duerst wrote:
> Again, looking

Nor is com associated with a single script.

I.e. I think you've taken a step in the right direction, namely:

language -> script

But I believe it would be a good idea to consider taking another step in 
the same direction:

language -> script -> character set

StringPrep and NamePrep are great, but I wonder if it might be good to 
take their ideas one step further to solve the IDN spoofing problem. 
I.e. to "normalize" the homographs by mapping the similar-looking 
characters to "base" characters.

For example, Cyrillic small 'a' would be mapped to Latin small 'a', 
since they are virtually identical (and, indeed, given the same glyph 
index in some fonts, I hear).

Of course, this idea is likely to be extremely controversial since any 
pair of characters that look similar to one person will look different 
to another.

Erik

---

From: Erik van der Poel <[email-masked]>
Date: Thu, 17 Feb 2005 08:20:21 -0800

William Tan wrote:
> For a gTLD, the language tag comes in handy, so we 
> intended language.

This is not really in the spirit of DNS itself, though. Before IDN was 
invented, people registered domain names that weren't in any language. 
For example, the name "microsoft" was not a word in any language when it 
was first introduced.

So it is not really fair to the IDN registrants to require them to state 
what language or set of languages their domain name is intended to be 
in, since DNS has not previously imposed such a restriction, and a lot 
of domain names have already been registered under this relaxed convention.

Erik

---

From: "Doug Ewell" <[email-masked]>
Date: Thu, 17 Feb 2005 08:36:28 -0800

Erik van der Poel <erik at vanderpoel dot org> wrote:

> For example, the name "microsoft" was not a word in any language when
> it was first introduced.

I hope Erik is able to get this message across, because I haven't,
despite many attempts.

For each of the following domain names, determine the "intended
language":

* google
* altavista
* yahoo
* m-w
* taco (this one may surprise you)

-Doug Ewell
 Fullerton, California
 http://users.adelphia.net/~dewell/

---

From: "Martin v. Löwis" <[email-masked]>
Date: Thu, 17 Feb 2005 17:42:46 +0100

> characters to "base" characters.

Only by means of blocking registration. A registration can be blocked
not only because it violates static rules, but also because it is
(or could be) a homograph for a different, already registered, label.

This is indeed the case already in .COM for Chinese labels: registration
of a single label blocks an entire family of labels - not necessarily
homograph ones, but labels that Chinese readers would consider "same".

Regards,
Martin

---

From: Erik van der Poel <[email-masked]>
Date: Thu, 17 Feb 2005 08:42:13 -0800

> * taco (this one may surprise you)

I have another one to add to the list: kazaa.

Erik

---

From: "Martin v. Löwis" <[email-masked]>
Date: Thu, 17 Feb 2005 17:48:51 +0100

> * taco (this one may surprise you)

English.

Etymology does not matter as much as scripts in use, for the
application under discussion (DNS).

Regards,
Martin

---

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

> (or could be) a homograph for a different, already registered, label.

I think it would be good to consider mapping homographs in the 
application too. For example, what if a user finds a domain name (or 
URI) in a magazine and then wants to type that into a Web browser's URI 
field? The most natural keyboard input language to choose is the user's 
(main) language. If one of the characters in the domain name is a 
homograph, then the user might type the "wrong" character, i.e. the 
wrong character code. She might type Cyrillic small 'a' instead of Latin 
small 'a'.

Wouldn't it then be the responsibility of the browser to map the "wrong" 
character code to the right one before sending it to a DNS server? 
Otherwise, DNS would not be able to find the right domain name.

Erik

---

From: "Martin v. Löwis" <[email-masked]>
Date: Thu, 17 Feb 2005 20:14:10 +0100

Erik van der Poel wrote:
> application too.

I strongly disagree. First of all, the algorithm used in IDN*A*
is already defined, changing it in any way or form will take decades,
and likely not happen in our lifetime.

 > For example, what if a user finds a domain name (or
> (main) language.

Wrong. The most natural keyboard input in this case is the apparent
script of the label. The user should see the script from reading
it - in some cases, even just from hearing it spoken.

> If one of the characters in the domain name is a 

By the same reasoning, you might want to map "mikrosovt.com" to
"microsoft.com", because the sound of them is the same.

> character code to the right one before sending it to a DNS server? 

Not it all. It is the responsibility of the "system" (including browser
and DNS server) to report an error that the domain cannot be found if
it is spelled incorrectly.

> Otherwise, DNS would not be able to find the right domain name.

And that would be a good thing.

Regards,
Martin

---

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

Martin v. Löwis wrote:
> The most natural keyboard input in this case is the apparent
> it

OK, I see. Thanks for taking the time to respond.

Erik

---

From: Martin Duerst <[email-masked]>
Date: Fri, 18 Feb 2005 11:40:01 +0900

>So it is not really fair to the IDN registrants to require them to state 
what language or set of languages their domain name is intended to be in, 
since DNS has not previously imposed such a restriction, and a lot of 
domain names have already been registered under this relaxed convention.

Very much agreed. Except for registries with very special
policies (such as the blocking used by some East Asian
registries), the language association doesn't make too
much sense.

Immagine that a gTLD registry had a few hundred language tables,
and immagine that a registrant wanted to register a particular
sequence of characters. It would be very easy for a registrar
to set up a service that figured out a language (don't care
which) that worked, and register the name with that language.

Regards,   Martin.

---

From: Martin Duerst <[email-masked]>
Date: Fri, 18 Feb 2005 14:21:29 +0900

Hello James,

Many thanks for your private answer. I'd preferred to have this
discussion in some public forum, so please feel free to forward
this to one of the lists where I'm involved.

At 02:53 05/02/18, James Seng wrote:
 >when we do idn, we talk about unicode and scripts. afterall, unicode is a 
script based encoding so it is silly to think in language.

Very good point.

 >but when you deal with end-users, lay-person who wants their idn, they 
thinking of names. they want names in their own languages. script? what's 
the different.

They want the names in their own characters. Some, maybe quite
a lot, of users may think about it in terms of language, but
there is no need to stress the language aspect more than
necessary.

Also, if the average user gets that policy, but Verisign doesn't,
that's much more damaging than the other way round.

 >that's the gap between the two. that's why in rfc3743, we talk about how 
to do chinese idn, japanese idn and korean idn and not han ideograph idn.

For rfc3743, that's fine, because that's dealing with language and
using language to address problems. Or actually, to be more precise,
it's not fine, because the main concern of rfc3743 isn't maybe
so much necessarily language as different ways to write the same
language. Simplified and traditional Chinese are not two different
languages, at least as I understand.

Another problem is that in different parts of the world, the issues
are diffenent. Switzerland is a good example, they didn't publish a
German table, a French table, and so on, for very good reasons.
It shouldn't look like they violate the ICANN policy, but at
the moment, it does look like they violate the policy because of
the way the policy is written. If that's by design, it's bad
design.

I'm not asking to remove all instances of 'language' from that
policy, but having 'language' 19 times and 'script' 0 times
in that document gives completely the wrong impression.

Regards,    Martin.

 >james
 >
 >On 17-Feb-05, at PM 08:39, Martin Duerst wrote:
 >
 >> Hello James,
 >>
community is by design.
 >> >> >Seriously, would you please elaborate on your ideas for .com? I 
would really like to know what you have in mind, specifically, to combat 
the homograph problem.

---

From: "Martin v. Löwis" <[email-masked]>
Date: Fri, 18 Feb 2005 09:21:06 +0100

> which) that worked, and register the name with that language.

However, as the East Asian languages might cause blocking,
every .COM user is required to provide a language tag. So
in that sense, every gTLD will have very special policies.

Regards,
Martin

---

From: Erik van der Poel <[email-masked]>
Date: Fri, 18 Feb 2005 03:37:25 -0800

> in that sense, every gTLD will have very special policies.

The .com and .net domains are operated by VeriSign:

http://icann.org/faq/#regrules

VeriSign appears to have adopted the Chinese blocking:

http://verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/idn-standards/idn-character-variants/page_002087.html

Do you know whether any of the other gTLDs have adopted the Chinese 
blocking?

Also, does any registry have blocking for any languages other than Chinese?

Thanks,

Erik

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 18 Feb 2005 13:16:49 +0100

>The .com and .net domains are operated by VeriSign:

I understand from sales and renewals that the registrants also have adopted 
a Chinese blocking.
I suggest you also go and visit the CNNIC site when you consider Chinese 
issues.
jfc

>Do you know whether any of the other gTLDs have adopted the Chinese blocking?

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 18 Feb 2005 13:11:16 +0100

could we for once call a cat a cat?

As noted in an earlier mail, we are neither speaking of language, script, 
countries: we are speaking of tables, and therefore of IDN 
tabtags.  Whatever the reason a sovereign ccTLD Manager has to enter a code 
into a table, the code is in the table.  So please stop arguing on the 
possible reasons, etc. A computer only considers the bits you put into a 
format, not your reasons.

There are three technical layers involved (internationalization, 
multilingualization and vernacularization) plus ccTLD's usual societal, 
economical and political considerations as in every other internet 
governance issue. If you want to advize them, just fine. But IETF is only 
concerned by the provision of the tools they needs. Today the IDNA solution 
is not addressing their needs, but it is here. No other solution will be 
provided by the IETF, however some refinements can be brought, at least 
through RFC for information to avoid a total fragmentation of the Internet 
between Lagacy and NGN. Among them:

1. a BCP commenting the RFC 3490 introduction to permit ITLDs (not the best 
and correct solution, but the only one permitted in this DNS current 
incoherence).

2. a better doctrine concerning the DNS virtual zones management to take 
into account tabtags in the NIC organization, since they were not permitted 
to be real zones.

3. a better relation between tables and lingual and vernacular aspects, 
with probably more general tabtags (ex. an extended European Latin table 
for all the characters European people understand as different).

The rest will be most probably addressed as usual by an open grassroots 
process, a "Language P2P like" process, part of the necessary technology 
evolution. Outside of the IETF virtual and of the W3C private worlds. The 
only result of all this will have been another 10 years wasted.

jfc

At 06:21 18/02/2005, Martin Duerst wrote:
> >when we do idn, we talk about unicode and scripts. afterall, unicode is 
> a script based encoding so it is silly to think in language.
>
>Very good point.
>

---

From: William Tan <[email-masked]>
Date: Sat, 19 Feb 2005 02:15:56 +1100

Hi Martin et al,

> registries), the language association doesn't make too

Indeed, for registries that wish to support CJK languages by following 
RFC3743, it makes sense to find out the intended language of a label in 
order to decide whether to apply traditional/simplified Chinese 
bundling. Take for example a label that contains only Han characters. 
When used in a Japanese context, there probably wouldn't be any variant 
that the registrant would care about. But when the same label is used in 
a Chinese context, assuming that it does mean something, the registrant 
might want both the traditional and simplified variants of the label.

Quoting John in draft-klensin-reg-guidelines:

   ...and with different geographical and political locations
   and languages having requirements for different collections of
   characters, the optimal registration restrictions became, not a
   global matter, but ones that were different in different areas and,
   hence, in different DNS zones.

It is my belief that CJK is not the only "problematic" or special cases. 
As languages are being researched on in terms of their implications in 
IDN, more language-dependent rules may need to be accommodated.

> which) that worked, and register the name with that language.

There is nothing wrong with this approach, technically. The language tag 
is, the way I see it, simply a hint and is more an administrative piece 
of information rather than concerning the operations of the DNS. It is 
used only at registration time, to allow the registry to make certain 
decisions and apply rules to it. If we could drop the word "language" 
and simply stick with "tag", then that tag could be a script, subset of 
a script, or simply a list of characters, labeled by a suitable term 
such as "Characters used in Germany", "Nordic languages", or "List of 
allowable characters for Japanese".

Take the .PL IDN program for example, as long as the desired label 
contains only characters from one of the allowable tables, the 
registration will go through. The tables are named "Latin set", 
"Cyrillic set", "Greek set", etc. They could jolly well launch Chinese 
and introduce a rule that says, if your label fits into the Chinese 
table, we will reserve any variants of it as well. One could see that as 
associating an IDN with a table, and the table may be a single language, 
or may represent several languages.

IMO, whether it is "language association" or "table association", they 
are one and the same concept.

Regards,
wil.

---

From: William Tan <[email-masked]>
Date: Sat, 19 Feb 2005 02:28:06 +1100

Hi Erik,

> Do you know whether any of the other gTLDs have adopted the Chinese 
AFAIK, CNNIC and TWNIC are the only two that do Chinese bundling. But 
their activation policy differs from Verisign's.

> Also, does any registry have blocking for any languages other than 
Check out the Persian IDN testbed project at IRNIC. They have a bundling 
policy.
There may be other registries out there implementing bundling that I'm 
not aware of.

Regards,
wil.

---

From: Martin Duerst <[email-masked]>
Date: Sat, 19 Feb 2005 10:32:47 +0900

I'd also look at SGNIC (Singapore).

 >Check out the Persian IDN testbed project at IRNIC. They have a bundling policy.

I looked at the presentation they gave at ICANN. With respect to
bundling,..., they are doing the right thing, I think.

Regards,   Martin.