Subject: RE: [idn] homograph attacks

From: "Kane, Pat" <[email-masked]>
Date: Wed, 16 Feb 2005 08:05:50 -0500

Jefsey,

1.  The language tags that we permit are a subset of the languages within
ISO 639-2.  The list of these can be found at
http://www.verisign.com/static/002533.pdf.  The IANA server is a listing of
language tables to be used with a language tag.  Commonality amongst TLDs in
general would be good.  That is why VeriSign uses tables such as those from
JET and others.
2.  I am interested in the French and Ukrainian sets as well as all of the
others that we permit that currently do not have language tables.  I have
not seen them so VeriSign does not have a table for either of those valid
language tags.  We are deploying this year those that have been posted on
IANA and are appropriate sources.
3.  We follow tables as published.  We do not develop these tables on our
own as there are more appropriate sources.  We did recognize that with
Cyrillic based languages there was a possibility of inappropriate
commingling of characters so we excluded all Latin and ASCII characters with
the exception of 0-9 and the dash.
4.  I am not sure of your exact question here, but in the registration
process each registrar actually encodes the characters and passes to
VeriSign the encoded string.

 Pat

-----Original Message-----
From: JFC (Jefsey) Morfin [mailto:[email-masked]] 
Sent: Tuesday, February 15, 2005 7:44 PM
To: Kane, Pat; "Martin v. Löwis" ; tedd
Cc: [email-masked]; [email-masked]
Subject: RE: [idn] homograph attacks

Dear Pat,
I have several questions here.

1. where do you maintain an ASCII list of your language tags? Should it not 
be supported on the IANA server and common to all the gTLDs?
2. is there a list of the permitted UNICODEs codes per languages? For 
example I am interested in the French and Ukrainian sets.
3. did you decide them by yourself, or did you gather a group of lingual 
authorities to assist you. This would be very interesting.
4. would there not be a way to register IDN in using their  "xn--" version? 
It would simplify international management by resellers?

Thank you for your assistance.

At 20:30 15/02/2005, Kane, Pat wrote:
>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
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>"Martin v. Löwis"
>Sent: Tuesday, February 15, 2005 2:02 PM
>To: tedd
>Cc: [email-masked]; [email-masked]
>Subject: Re: [idn] homograph attacks
>
>tedd wrote:
> > You all knew this was going to happen.
> >
> >    http://www.p&1072;ypal.com
>
>Indeed. However, I am somewhat disheartened that this could
>happen. IMO, Verisign should have never have registered that
>domain - the registrar should have provided a language for
>the label, that language should have been "Russian" (or
>else &1072; should not have been allowed), and this combination
>of Cyrillic and Latin letters should not be allowed for the
>Russian language.
>
>Regards,
>Martin

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 16 Feb 2005 15:09:43 +0100

Dear Pat,
Thank you for your response. Let assume this list is the missing 
International coordination list.  As you know we are in a gray situation 
regarding the IANA and language tags. There is the RFC 3066 which accepts 
ISO 639 as a reference and which permits the language "specialists" (ISO 
and W3C) of the http://www.alvestrand.no/mailman/listinfo/ietf-languages 
mailing list to discuss missing languages. This is clean.

But then we have a confusion.

1. When you register a IANA tag, you are to register it by language, script 
and ccTLD. This is clear.

2. W3C discovered that a language tag by ISO 639 was not enough to describe 
an XML document. So they introduced two new ideas the IESG could buy: '(1) 
RFC 3066 language tags could become ISO 639+ISO 15924 script+ISO 3166 
country code (2) that _all_ the langtags should be resgitered, not only the 
additions. So, each language is known as a single version - what culture 
people shout at!

When explained the conflict with IDN they claimed they do not care. IMHO we 
have a layer violation because I see three layers to support the users demand.

1. internationlisation: this is the IDN and the ccTLD (quoted in the 
language/script/ccTLD sequence is the authority). So the default should be 
the IDN Table assuming that ccTLD Managers are the trustees of their 
communities and know better about their people than anyone else.

2. multilingualization: thus is an added layer to take care of the 
language, the semantic, the dictionnary, the grammar, the culture, etc. You 
can have many visions. I said the ccTLD vision should be the default and 
described in IDN Tables, then univesities, Govs, artists, writers, etc. can 
have theirs. So the tag should include language.script/ccTLD/authority.

3. vernacularization: the way the user is to use the language through 
applications. This means that an additional element will be the style. This 
makes a lang5tag including language/script/ccTLD/authority/style. There the 
application may use the style to warn about a possible spoofing or not.

In addition to the lang5tag proposition - I propose we agree upon an 
XML,ASN.1 format to decribe a TLD better than the current Whois, where the 
TLD Manager would describe far more elements including its Tables in a 
computer readable form, so we could easily share the definition. For 
example this could include a list of foul names to bar in the language, of 
famous contious marks, etc. We (TLD Registries) could decide to maintain 
this file available at some published addresses for direct mutual exchange.

>general would be good.  That is why VeriSign uses tables such as those from

I would appreciate if we could have it in ASCII in a stable format, so we 
could work on automating reading of these data.

>IANA and are appropriate sources.

I have no problem to Publish mine in French. May be could we discuss that 
together?

>the exception of 0-9 and the dash.

When you say "published" you mean IANA? I think we need something more 
reactive and more multingual. Is Nico Popp still invoved in IDNs (he is in 
the MINC Board for you?)

>VeriSign the encoded string.

As a "reseller" myself, I would like to be able to enter my encoded string, 
for it to be verified and registered. I have ASCII tools. What is true for 
the DNS is also for me.

All the best.
jfc

---

From: John C Klensin <[email-masked]>
Date: Wed, 16 Feb 2005 12:17:58 -0500

Responding to several messages together, rather than sending a
series of fragmented messages...

Folks, I'm pleased to see so much interest on this list, but
note that the issue has already been extensively discussed on
the IETF list and elsewhere.  I'm copying Tina Dam, who has the
IDN lead for ICANN, on this message; if there is further
traffic, you might want to include her as well (or, for the
reasons discussed below, she might want to move part of the
conversation to an appropriate ICANN list).

--On Wednesday, 16 February, 2005 15:09 +0100 "JFC (Jefsey)
Morfin" <[email-masked]> wrote:

>...
> Thank you for your response. Let assume this list is the
> missing International coordination list.

While I think that an "International coordination list" would be
helpful, my assumption is that ICANN's idn-discuss list (see
http://www.icann.org/topics/idn.html for subscription
information and some other information that might be useful) is
intended to serve that purpose.  It is pretty clearly not this,
or any other, IETF list: the IETF made a series of fairly
explicit decisions to not get into the business of deciding what
things could or could not be registered within the very broad
coding mechanisms specified as part of IDNA.

>  As you know we are
> in a gray situation regarding the IANA and language tags.
> There is the RFC 3066 which accepts ISO 639 as a reference and
> which permits the language "specialists" (ISO and W3C) of the
> http://www.alvestrand.no/mailman/listinfo/ietf-languages
> 1. When you register a IANA tag, you are to register it by
> language, script and ccTLD. This is clear.

Actually, that is not the ICANN/IANA requirement, nor is it
clear where their requirement applies (e.g., such registrations
are optional).  Their requirement is unclear and, IMO, needs
updating.  I hope that they will get to that updating process
RSN.  On the other hand, I have had that hope for well over a
year.  Progress is unlikely to be made on those subjects by
further discussion here.

>...
> 1. internationlisation: this is the IDN and the ccTLD (quoted
> in the language/script/ccTLD sequence is the authority). So
>...

Jefsey, as you know, we do not agree on your analysis of
language and cultural issues and how they relate to the
Internet's protocol suites or the DNS and agree even less with
your model of how the DNS works and its role in the world.  We
also disagree on what appears to be your desire --exhibited by
citing OPES as an Internet norm-- to move all sorts of issues
from the edges of the network to the center.  For me, one of the
major strengths of the Internet, and a key reason it has been
deployed worldwide and achieved as much penetration as it has,
is that it strongly resemblances an "edge"-based network and has
avoided the many traps associated with a design in which
significant functionality, especially significant applications
functionality, is located in between peers or clients and
servers   I won't reprise the rest of  my side of that
disagreement here.

In a separate note, at Tuesday, February 15, 2005 7:44 PM, you
wrote, in part...

>> Should it not be supported on the IANA server and common to
>> all the gTLDs?

I agree with Pat that commonality --among gTLDs and even more
generally -- would be a good thing, especially for the would-be
registrant who wishes to register the same name in multiple
domains.  But ICANN has so far chosen to not to try to impose
it, and I hope they don't.  We have so far discovered at least
two things that may argue for caution in this area:

	(i) As I trust everyone on this list knows, phishing is
	only part of a far more general set of issues that can
	cause end-user confusion (whether through accident or
	malice).  For any given domain, there is a tradeoff
	between maximum safety (which might require permitting
	only a small number of characters and imposing
	significant restrictions on how they are used) and
	maximum registration flexibility (which might argue for
	much more flexible rules).  In my personal opinion, at
	least, it is far better for the Internet to let domains
	compete on how protective or flexible they want to be,
	assuming the advantages and risks of whatever solution
	point they pick, than to try to impose some Procrustian
	solution.
	
	(ii) An interesting distinction has been identified
	between the needs of a domain that must serve the
	requirements of a particular country and a domain that
	supports the language commonly associated with that
	country.  For the first case, of which .DE is the
	best-worked-out example, there is a legitimate
	requirement for registration of common names, company
	names, street names, etc., in Germany.  Given history,
	that list will include strings and characters that don't
	exist in the German language.  It may include strings
	the contain combinations of characters that do no appear
	together in any contemporary language that uses
	Roman-based characters.   By contrast, if a gTLD creates
	a language table defined around the German language,
	many of the characters needed by .DE are simply invalid.
	That contrast, which Martin has identified in the form
	of the difference between the "German" tables used in
	the TLDs for Austria and Switzerland relative to those
	used in Germany) may require taking a different look at
	the rules and guidelines (and table registration models)
	than we have heretofore taken: either for rather
	different guidelines for ccTLDs than for gTLDs, or for
	rethinking the registration model, or both.

	The issue that Pat identifies with Tajik is another
	piece of the same puzzle: many of us may believe that
	there is no possible reason to mix the three scripts in
	which that language can be written in a single label,
	and I certainly trust Roozbeh's knowledge and experience
	in that area. Certainly, it would make things safer to
	prohibit any mixing (note that IDNA's BIDI restrictions
	essentially prohibit mixing an Arabic-derived script
	with anything other than itself, another Arabic-derived
	script, or Hebrew).   However, we have a long history of
	DNS labels that could not possibly be words in any
	language.  Whether or not to permit mixed-script labels
	is presumably an issue that the registry for .TJ will
	need to sort out (I have been told, for example, that
	mixed Cyrillic and Latin-character labels are likely to
	be a requirement in Serbia and Montenegro, although this
	illustration might give them pause).  And the best
	answer for them might or might not be the best answer
	for a gTLD.

In addition, as Hotta-san's very helpful note points out, one
could considerably reduce the scope of the identified
confusion/phishing problems by aggressively applying a variant
model across scripts, restricting the registration of homographs
to the same registrant.  I personally suspect that will not
prove practical, from a policy standpoint, in the collection of
alphabetic scripts that share Old Semitic origins, but that is,
IMO, just another argument for giving different registries the
flexibility to develop their own policies and take
responsibility for the consequences of those policies.

Again, these issues need to be worked out in an ICANN forum; the
IETF has thrown the problem over the wall and shows no signs of
wanting it back.

--On Wednesday, 16 February, 2005 08:07 +0100 "\"Martin v.
Löwis\"" <[email-masked]> wrote, responding to Soobok Lee:

>> All Cyrillic  label  "HP" (.com)  can be registered even in
>> Russian  language pack.
>> 
>> Cyrillic "HP".COM  in its uppercase form  looks the same as
>> all ASCII   "HP.COM".
>> 
>> Any Registration Process should filter out these "HP" like
>> combinations..

But the only way to do that would require that a domain that
permits Cyrillic characters must ban ASCII characters and vice
versa.   I would predict that will just never happen, if only
because every domain that exists today has a long of all-ASCII
labels in it.  It is not a very good example (see below), but I
note that this particular example is only of the reasons why
"identify a mixed-script label in the application" may be a
useful tool, but is not a solution -- this is not a mixed-script
label.

> I think this is unreasonable. The lower-case forms ("??" vs
> "hp")
> look quite differently, and browsers typically display domain
> names in all-lower in the address bar.

Regardless of what browsers do (there is a case to be made that,
for traditional labels, if they get an all-upper-case label back
from a DNS query and display it in lower case, they are
violating the intent of the spec), note that, for IDNs, mapping
through IDNA and back (ToUnicode followed by ToASCII) will
always result in lower case and application of several other
mappings.

>...
> just because they are homograph with a latin combination. Then,
> the same would apply to Greek vs. Cyrillic.

Yes, banning a mixture of Latin characters with those of any
other script won't work either because one can get homographs
among other pairs of scripts.  However, it might be realistic to
ban the combination of Greek and Cyrillic in the same zone,
while it would not be practical to ban the presence of
Roman-based characters with either.  Mostly, again, this points
out the importance of zone-specific policies that are
well-tailored to the needs of that particular zone.

To repeat what I have said on the IETF list and elsewhere,
nothing is going to make these issues 100% foolproof or easy.  A
number of tools may help.  Certainly carefully-designed
restrictions on what can be registered in a particular zone and
what characters can be used together in the same label will
help.  Intelligent and well-thought-out use of variant models
may help a good deal.  If labels that can be identified as
having no use other than to confuse or defraud can be rejected
at registration time, that would eliminate a lot of problems
down the line -- that may be practical in some cases but not in
others.  I'm a bit skeptical about identification of
mixed-script labels in applications, not because I think it
wouldn't be useful, but because carrying those tables around and
keeping them up to date could be a bar to implementation and
performance, but there may be ways to make it practical.  I
think users --both those whose preferred scripts are written in
Roman-based characters and those whose preferred scripts are
not--  are going to need to become educated about some of these
issues, not just to protect themselves but to understand when
IDNs or IRIs can be exchanged with others with high odds that
they will be usable and unambiguous.   I think there is a lot of
potential in distinctions like the Firefox one between "copy
link location" / "paste link" and "copy"/"paste" and that we may
discover that the former pair should convert to punycode and
URIs and back to UTF-8 (or whatever) and IRIs to prevent
inter-application and inter-system cut and paste problems.

And I hope we can all figure out a way to work together to make
this work.  It is important, "don't use IDNs" isn't an answer
now and never has been, and the alternatives are just a choice
among ways to fragment the Internet.

     john

---

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

JFC (Jefsey) Morfin wrote:
> 1. When you register a IANA tag, you are to register it by language, 
> script and ccTLD. This is clear.

I don't see how this is relevant for this discussion. If the .com
registrar decides to use a subset of 639 only, I consider this a valid
choice. No need to register any language tag with IANA; all tags
you ever want to use are already there.

> 2. W3C discovered that a language tag by ISO 639 was not enough to 
> describe an XML document. 

This is completely unrelated to IDN.

> language/script/ccTLD sequence is the authority). So the default should 
> be the IDN Table assuming that ccTLD Managers are the trustees of their 

Sounds like a reasonable approach; it appears that Verisign is using
it.

Regards,
Martin

---

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

John,
I replied privately to most of your points which are not related to my mail 
to Pat Kane. I want however to address one of your suggestion in here as it 
is of interest to everyone to understand what is the real situation.

At 18:17 16/02/2005, John C Klensin wrote:
>intended to serve that purpose.

I suggest everyone to access the archives of that ICANN list dedicated to 
the IDNA deployment.
http://forum.icann.org/lists/idn-discuss/
1. one welcome
2. one broadcast
3. three phishing mails

>  It is pretty clearly not this,

This is why this list should probably be moved elsewhere when it starts 
discussing real issues.
jfc

---

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

Hi John,

It's been a while!

In fact, it's been so long since I've really taken part in any RFC or 
Internet Draft related discussion that I'd like to apologize in advance 
if the following questions are, um, stupid...

> coding mechanisms specified as part of IDNA.

I had a look at the welcome message of the idn-discuss list at ICANN, 
and it seems to be aimed more at the registry operators. I was hoping to 
find a forum where a broader group of interested parties could discuss 
the issue of IDN spoofing. I'm thinking of IDN applications, domain 
registries, ICANN and even IETF.

The reason I include IETF in this list is because I believe the IDN RFCs 
are a product of the IETF, and (1) those RFCs are not at the Standard 
Maturity Level yet, and (2) any discussion of IDN spoofing should 
probably include a discussion of the nameprep spec, since that may be 
something we could tweak, to help solve the problem.

If, as you say, the IETF has decided not to get into the business of 
deciding what can and what cannot be registered, then I suppose a forum 
centered on the registries (probably ICANN?) would be best.

But then I still wonder what forum is going to be discussing the IDN 
RFCs when they attempt to climb to the Draft Standard Maturity Level. I 
note that the IETF IDN WG has concluded.

Also, I saw that you published a new version of your IDN guidelines:

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

Where is this I-D to be discussed?

Thanks,

Erik

---

From: Martin Duerst <[email-masked]>
Date: Thu, 17 Feb 2005 18:46:16 +0900

Hello John,

Some points below.

 >year.  Progress is unlikely to be made on those subjects by

I'd be glad to hear about what you think needs updating
(I'm thinking there is a need for updating, too), in
any appropriate venue. (I subscribed to the ICANN
list you mentioned)

 >	rethinking the registration model, or both.

I think the idea of a gTLD serving German language needs
is not necessarily helpful. Of course they need to serve
German language needs, as well as the needs of many other
languages. But do they have to say "oh, well, .DE developped
this table for the needs in Germany, including the needs of
the German language as a subset, so we should try and find
that subset"? I'd claim that that's mostly investing work
at the wrong place. In many cases, a gTLD can just create
tables that cover a number of languages at the same time,
maybe even a whole script as proposed by Michel. But this
has to be done bottom-up, so it may take time.

 >	in that area.

Very much agreed.

 >      Certainly, it would make things safer to
 >	script, or Hebrew).

Good point, but a small correction:
These restrictions only prevent mixing RTL scripts (Hebrew,
Arabic, Syriac,...) with LTR scripts (all the others). They
don't prevent mixing RTL scripts among each other.

And of course, exceptions such as Japanese as well as
languages that e.g. use a few Greek characters in addition
to the Latin alphabet have to be addressed (such languages
of course use those characters from Greek that look different
from Latin characters, so there should be no, or not much,
of a phishing issue).

 >      However, we have a long history of

I'm a bit sceptical for the need for true mixed-script labels
for Serbian (i.e. something like latin-CYRILLIC). One main
issue here is that it's more work to type in mixed-script
labels.

 >responsibility for the consequences of those policies.

I share your suspicions. The 'variant reservation model'
was carefully worked out to address concerns about
simplified/traditional Chinese. Even the Japanese, who
participated in working out this model, haven't adopted
it for themselves, although there is a considerable
amount of simplified/traditional variants in Japanese,
too (though less than in Chinese).

 >L$B‹X(Bis\"" <[email-masked]> wrote, responding to Soobok Lee:
 >

There is one possible scenario where this might happen.
If there is e.g. a Cyrillic equivalent to .ru, it is very
probable that the Cyrillic registrations will go into that
equivalent rather than into .ru, because a series of
Cyrillic labels looks better, is easier to read, is easier
to remember, and is easier to type than mixed labels.
If such a tendency gets firmly established, it could be
possible to at some point simply say that Cyrillic registations
go into the Cyrillic TLD, and Latin registrations go into
the Latin TLD. Of course, there are a lot of things that need
to happen before we could get to such a state, but it's at
least a scenario.

And please notice that spoofing in TLDs isn't a problem,
because TLDs can simply be designed to avoid homographs;
the Cyrillic equivalent of .ru would be choosen to not look
like .py (Paraguay), but maybe something like Cyrillic r
(looks like p) followed by a short i (looks like (small)
mirrored N with a hook on top).

 >among ways to fragment the Internet.

Yes, this is the most important point!

Regards,    Martin.

---

From: Martin Duerst <[email-masked]>
Date: Thu, 17 Feb 2005 18:24:09 +0900

>you ever want to use are already there.

Not exactly correct. For cases like Serbian, Azerbaijani, Tajik,
which can be written with different scripts, you need more than
ISO 639. Serbian and Azerbaijani have script variant tags registered
at IANA (see http://www.iana.org/assignments/language-tags); Tajik
doesn't (yet). There is a draft
(see http://www.ietf.org/internet-drafts/draft-phillips-langtags-10.txt)
that makes script codes generative, i.e. they don't have to be
registered anymore.

[incorrect; extending ISO 639 with country codes was done by RFC 1766,
with the main input comming from email]

Regards,    Martin.

---

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

Martin Duerst wrote:
> ISO 639.

Please read my statement again. *If* the registrar decides to use
a subset of 639 only, *then* all tags you ever want to use are
already there.

Now, the question is how the registrar deals with 639 languages
that use multiple scripts. There are two obvious options:
1. all characters in any of the scripts of the language can be
    allowed in a domain label (allowing for unintended homographic
    labels)
2. the characters of the language are separated into disjoint
    scripts, and each label registered for a language is required
    to fall into one script.

There are other options as well, of course: the registrar could
try to block labels in other scripts than the registered one,
if they are transliterations of each other. For example, for
Tajik, it might be sensible to block a Latin label if the
equivalent Cyrillic one has been registered.

Regards,
Martin

---

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

>a subset of 639 only, *then* all tags you ever want to use are

Sorry, but that reading of the sentence was too trivial
for me to consider it.

 >equivalent Cyrillic one has been registered.

Yes, that's more or less the choices they have. (1) is the
dangerous one, (2) is the easy one, and your transliteration
example may be easy or hard depending on the language.

Regards,    Martin.