Subject: [idn] IDN spoofing

From: Erik van der Poel <[email-masked]>
Date: Fri, 18 Feb 2005 05:41:45 -0800

All,

This email is being sent to both the Unicode and IDN mailing lists. I'm 
wondering how we can move forward with the IDN spoofing issue. Let me 
take a stab at it.

Regarding the proposal to unify (or map) all the homographs, Doug Ewell 
wrote a humorous email illustrating how difficult such an effort would be:

http://ops.ietf.org/lists/idn/idn.2002/msg00498.html

John Klensin says that a "one label, one language" rule has been 
suggested to combat look-alike confusion. See section 1.5.1 in:

http://www.ietf.org/internet-drafts/draft-klensin-reg-guidelines-06.txt

Indeed, this label-based idea makes sense because DNS is 
administratively divided into labels. For example, the .com operator 
might be able to impose some restrictions on the 2nd level domain label, 
but if someone registers foo.com, then it's up to them to decide what 
will be allowed at the 3rd level (e.g. bar.foo.com). No?

Recent discussion on the IDN mailing list has suggested that we might 
want to think more in terms of *script* than language. However, I note 
that there is a very diverse history of mixing scripts:

http://ptolemy.tlg.uci.edu/~opoudjis/unicode/unicode_mixing.html

But do we really need to allow for such rich script mixing in DNS? Some 
of the script mixing described in the document above is scholarly 
transliteration or "one-offs".

So, instead, I propose that we start thinking of a "one label, one 
writing system" rule. The Unicode book defines "writing system" as "a 
set of rules for using one or more scripts to write a particular language".

This makes a lot of sense for some of the ccTLDs. For example, the .jp 
domain could choose to allow the Japanese writing system in the 2nd 
level domain label.

But what can we do about .com? It's clearly a worldwide TLD now. It 
should probably allow multiple writing systems. Perhaps the .com 
operator could specify that 2nd level domain labels must stick to one 
writing system, and that that writing system must be indicated in the 
RRP (Registry Registrar Protocol) in order to validate the 2nd level 
name against the table of characters allowed in that writing system.

This would probably require a (new?) set of names for writing systems, 
somewhat similar to the language tags of ISO 639.

Some people might point out that it is unfair to impose a writing system 
rule on domain labels since DNS has not had such restrictions in the 
past. Or has it? The DNS spec itself may allow various octet values, but 
the infrastructure and conventions appear to be restricted to some of 
the ASCII characters, which I guess you could just call the English 
writing system, no?

Also, I'm guessing that any "one label, one writing system" rule cannot 
really be mandated, since TLD operators have historically been free to 
do whatever they want, to make as much money as they want. So this rule 
would just be a guideline (Klensin's document is titled "Suggested 
Practices ...") and the TLD operators could follow it, if they wish to 
combat the IDN spoofing problem more than they wish to make money (in 
the short term :-)

Erik

---

From: "Edmon Chung" <[email-masked]>
Date: Fri, 18 Feb 2005 09:35:30 -0500

----- Original Message ----- 
From: "Erik van der Poel" <[email-masked]>
> set of rules for using one or more scripts to write a particular language".

This is an intersting idea.  Based on the Unicode book though, there are 6 defined "writing systems"
- Alphabets (e.g. Latin, Greek, Cyrillic, Armenian, etc.)
- Abjads (e.g. Hebrew, Arabic, Syriac)
- Abugidas (e.g. Devanagari, Bengali, Gurmukhi, Gujarati, etc.)
- Logosyllabaries (e.g. Han)
- Simple Syllabaries (e.g. Cherokee, Hiragana, Katakana, Bopomofo, etc.)
- Featural Syllabaries (e.g. Ethiopic, Canadian Aboriginal Syllabics, Hangul)

And under the 6 writing systems are different "scripts".  It is not difficult, I suppose, to try to imagine "fitting" the phrase into a "language" context (i.e. as what you have described as a "Japanese writing system"), but I do not have enough expertise to say whether that is a good idea or whether it would invite other confusions and objections.

Rather than trying to "fit" an existing phrase into the context of IDN, perhaps it may be better to just invent a convention to describe what is actually happening and plausible given precisely the DNS context.

That is, rather than trying to use the words "language" or "writing system" or "script" which invites contention, why not just say that each registered IDN Label should have an associated "IDN-Tag".  And an "IDN-Tag" is defined by a domain registry and encompasses a policy profile that is developed by a local / lingusitic authority with rules relevant for IDN use.  This could include 3 general types of things:
1. the collection/list of valid characters/codepoints;
2. some contextual rules (if applicable); and,
3. considerations for variant preparations/reservations (if applicable).
(maybe more than 3 would be appropriate, I am just suggesting these as a starter)

Today, for example, the .JP registry has created its Japanese policy profile with a list of valid characters (which includes kanji, the kana's and LDH) with a couple of contextual rules (max length of domain is 15 native characters and some defined pre-mapping characters).  The .CN and .TW registries joined forces through the CDNC to develop the Chinese policy profile with a list of valid characters (which includes Simplified and Traditional Chinese characters as well as LDH) and considerations for variant mappings.

Note that both these "Domain-Langauge-Policies" in fact include multiple "writing systems" within one profile.  Both also included multiple "scripts" and even arguably multiple "languages".

As we continue to work on implementation of IDN, I have found that it is hard and often creates confusion when using overly generic words such as "language" and "script" because they generally come with a lot of baggage.  In order to clarify discussions and try to avoid convoluted debates which may be interesting buy ultimately confusing for lingusts and technologists alike, it seems that inventing a few phrases to give it a clear "IDN" context would be useful.

Just some thoughts...

Edmon

---

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

Hi Erik,

> But what can we do about .com? 

It's not about what we can do about it, but what Verisign wants. If 
Verisign wanted to strictly adhere to ICANN's IDN guidelines, it 
would've dropped support for languages for which they have no table, and 
Eric wouldn't have been able to register that twisted paypal.com. And if 
Verisign, in light of this homograph attack advisory, decides to play it 
right from now on, I'd be pretty much contented. Sure, there are other 
TLDs who are still registering IDNs with liberal rules, maybe we can 
convince them to follow suit, maybe not.

> It's clearly a worldwide TLD now. It should probably allow multiple 
> writing systems. Perhaps the .com operator could specify that 2nd 
> level domain labels must stick to one writing system, and that that 
> writing system must be indicated in the RRP (Registry Registrar 
> Protocol) in order to validate the 2nd level name against the table of 
> characters allowed in that writing system.

This is already the case in Verisign's SRS where registrars are required 
to submit an ISO-639 language tag via RRP.

> somewhat similar to the language tags of ISO 639.
What nifty features would this bring, if the registry does not attach 
any rules to the writing systems, as is the case with language tags now.

Regards,
wil.

---

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

>> Perhaps the .com operator could specify that 2nd 

I feel that it may be worth exploring whether we can come up with a 
distinct (from 639) set of names that more accurately matches the model 
I'm thinking of. See below.

> any rules to the writing systems, as is the case with language tags now.

Well, perhaps the tag passed in RRP would not simply identify a table of 
characters that are used in a writing system. Perhaps the tag would name 
a set of rules for a domain label, that includes having to use a table 
of characters.

This set of rules could, for example, include a rule that states whether 
and how Latin characters are allowed in a Cyrillic label such as the 
XML-ccccccc.com example mentioned earlier on the Unicode mailing list. 
(Here, the "ccccccc" are all Cyrillic characters.)

As was mentioned on the Unicode mailing list, the hyphen '-' could be 
used to separate the Latin from the Cyrillic. The Russian TLD .ru might 
want to have such a set of rules. (They probably already have some 
rules; I certainly am not trying to force them to adopt this proposal; 
it is merely an example.)

To continue this example, the .com registry might then wish to reduce 
confusion by adopting the same set of rules for Russian registrations 
under .com. This way, a registrant is confronted with a unified model 
and set of rules, whether they wish to register only under .ru or also 
under .com.

Of course, under this proposal, the guideline would no longer be called 
"one label, one writing system" because my proposed sets of rules would 
not really be exactly the same as "writing systems" as defined in the 
Unicode book.

So we might have to come up with a different term for these sets of 
rules. How about "label rules"?

Erik

---

From: Keld Jørn Simonsen <[email-masked]>
Date: Fri, 18 Feb 2005 20:06:12 +0100

> set of rules for using one or more scripts to write a particular language".

I think we should only try to address the DNS spoofing problem, while
allowing as much of business to be able to market themselves in an
adequate way. 

Why not allow Japanese characters in the Danish ccTLD?
I had a japanese restaurant on the opposite corner of my road, and I
have a Chinese restaurant just on the corner of the other end of my
road. Both were advertising ther foreign name on the street facade,
and on their bills and visit cards.  If a company is marketing
themselves in a script foreign to the country they are located, why
should we not allow it on the internet. The internet should follow
modern business practices.

Of cause we should minimize the risks for internet users of being
mislead. This could be done by equializing similar characters,
like Latin, Cyrillic and greek A, 0 and O, 1 and 1 etc, so that no
visual misleading should be possible.

Best regards
Keld

---

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

> rules. How about "label rules"?

I'm convinced that terminology is of least concern. No matter what
your terminology is (language tags, script tags, or DNS label tags),
it *is* a lot of work to come up with reasonable rules to simultaneously
allow registration of "valid" labels, yet rejecting spoofing
registrations. And the hard work is *not* in finding algorithms - the
hard work is in coming up with the data that drive the tables.

In that sense, Verisign's approach for .com is just right: we will not
create our own tables, we will use whatever tables national bodies,
(or perhaps the Unicode consortium), provide us. Each registrant needs
to identify which table a certain registration is meant to comply with;
it just happens that ISO 639 codes are used to identify the tables
(but Roman numerals would work just as well if the tables are
published).

As I said before, it is reasonable to err on the side of caution in
creating these tables (something that Verisign unfortunately does not
agree with); it will always be possible to extend the tables later.

So, to help the process, creation of tables for the various user
groups is necessary.

Regards,
Martin

---

From: John C Klensin <[email-masked]>
Date: Fri, 18 Feb 2005 15:13:04 -0500

--On Friday, 18 February, 2005 20:06 +0100 Keld Jørn Simonsen
<[email-masked]> wrote:

>...
> Of cause we should minimize the risks for internet users of
> being mislead. This could be done by equializing similar
> characters, like Latin, Cyrillic and greek A, 0 and O, 1 and 1
> etc, so that no visual misleading should be possible.

Keld, for better or worse, a decision was made to not try to do
this in IDNA.  At least one of the reasons is that the
definition of "similar" is much in the mind of the beholder.
The decision to treat 0 and O, 1 and l, as separate was made 20
(or, by a different line of reasoning, more like 34) years ago
and is irreversible at this point.  

For the more general case, U+0E02, U+0E03, U+0EA1 could all be
construed by someone who doesn't know which scripts they came
from as font variation on either U+0C35 or U+0055, so it isn't
at all clear how one would adopt general "equalizing" rules,
even if they were wanted.   The good news is that, should a
registry decide to use them, the "variant" model of RFC 3743
could be easily adapted to prevent labels that would equivalent
if these "equal in the mind of the registry" characters were
from being registered.   Personally, I find it rather attractive
that the decision as to whether or not to do that, and which
characters to consider too similar to permit labels built on
them to be registered to different parties, can be made one
registry at a time, with no need for global agreement about
those visual perceptions.

    john

---

From: Erik van der Poel <[email-masked]>
Date: Fri, 18 Feb 2005 14:09:54 -0800

Martin v. Löwis wrote:
> I'm convinced that terminology is of least concern.

I think I disagree. The term "language" is well known to many people, 
and has quite a different meaning from "table of characters". On the 
other hand, if you use the term "label rules" and then explain what 
those rules are for a given TLD, then it should be quite clear to just 
about anybody.

There are very few language tables registered in IANA's IDN registry, 
possibly because NICs like DE do not wish to specify a language or set 
of languages. :-)

Well, maybe they have other good reasons to refrain from registering 
their table.

The rest of your email was mainly about tables, leading me to suspect 
that you may have missed my main point, which is that a registry can 
impose *additional* rules, such as allowing both Latin and Cyrillic, as 
long as there is a hyphen between them. If you did not miss this point, 
I apologize.

Erik

---

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

> Why not allow Japanese characters in the Danish ccTLD?

I did not mean to imply that the ccTLDs would only allow their "own" 
languages. The Danish TLD could decide to accept registrations using 
"label rule" tags defined by other TLDs or organizations or individuals. 
If .com is allowed to adopt .ru's label rules for Russian registrations, 
then .dk should also be allowed to adopt label rules specified by other 
people.

Alternatively, the Danish label rules themselves could simply allow 
Japanese characters since they are unlikely to be confused with Latin 
characters anyway, but then you run the risk of confusing your 
registrants with rules for Japanese that are different from the rules 
for Japanese under .jp, so you may want to adopt .jp's rules.

That's your choice, and it's good that you have that choice, no?

Erik

---

From: Erik van der Poel <[email-masked]>
Date: Fri, 18 Feb 2005 15:06:02 -0800

Edmon Chung wrote:
> ...policy profile...

Yeah, maybe the term "policy profile" or "profile" is better than "label 
rules". I agree with you that "language" comes with a lot of baggage.

Erik

---

From: Erik van der Poel <[email-masked]>
Date: Fri, 18 Feb 2005 17:27:07 -0800

VeriSign folks:

I seem to have written something that might upset someone again. I am 
really sorry. You guys have done a lot of good work and put a lot of 
information on your Web site regarding IDN. A lot of it is educational 
in nature, and a lot of it seems to indicate that you have sound 
policies in place.

http://verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/index.html

It was unfair of me to accuse you (and other TLD operators) of only 
wanting to make money (and not being interested in the phishing problem).

I apologize, and hope that you will send comments to one or both of 
these mailing lists when you're ready.

Respectfully,

Erik

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 18 Feb 2005 21:54:32 -0800

> visual misleading should be possible.

OK, now fill in the "et cetera," now that you've got the obvious ones
out of the way.

As long as Erik has already mentioned it (thank you very much), see my
post from 3 years ago to see how this task quickly goes from simple to
tricky to impossible:

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