JPRS Statement: About Recent Articles Regarding Phishing Using Homographs among IDNs

[higashida@xxxxxxxxxx]

Dear ICANN,

I hereby submit the statement which JPRS, the .JP registry, had
announced and sent to ICANN on 14 February 2005, before this
public comment forum opened.
This statement had been posted on JPRS website as well.
URL: http://jprs.co.jp/en/topics/050214.html

Sincerely,

Koki Higashida
Japan Registry Service Co., Ltd. (JPRS)

====================================================================
About Recent Articles Regarding Phishing Using Homographs among IDNs
- Countermeasures Already in Place, and .JP Follows Them - 
====================================================================
Recently, several articles pointed out increased possibilities of
phishing/attacking using homographs through introduction of
IDNs. However, the essence of such problems is not rooted on the IDN
itself or its applications. Rather, it is based on how domain name
registries handle homographs among domain name strings. Here,
explanation is given from the following viewpoints:

- Root of the Problem 
- Existing Countermeasures Applied to IDN Registration by Domain Name
  Registries
- Measures already taken in Japanese .JP domain name registration from
  its beginning

It is worth stating here that, although homographs among domain names
are focused here, such visual illusion is not an effective means for
phishing, since actual phishing uses more sophisticated tricks such as
camouflaging or concealing false URIs.

--------------------------------------------------------------------
Root of the Problem
--------------------------------------------------------------------
Domain name is a character string. The variety of characters in domain
names expands and hence the number of similar-looking characters may
increase when IDN is introduced. Phishing using homographs among IDNs,
reported these days, is a trick performed by ill-willed website owners
by making bad use of similar-looking characters. Especially, the
example of recent articles claims that users of IDN-enabled browsers
may be visually illuded and phished by a false URL containing a
non-ASCII character similar to an ASCII letter.

The root of this problem is a visual illusion, which already existed
and was not originally introduced by IDN specifically. For example,
among ASCII characters, you will find 1 (digit) and l (letter l) are
similar-looking and so as 0 (digit) and O (letter O). These character
pairs can be used for visual tricks. However, it is true that
combinations of similar-looking characters increase when IDN is
introduced. For example, dash mark for prolonged sound and Kanji
character for 'digit one', which are both used in Japan, are very
similar-looking.

This problem was already identified when IDN was standardized and
introduced. Countermeasures to suppress the problem were already
investigated and published as RFC by IETF. In addition, guidelines for
domain name registries to conduct such countermeasures have already
been set up by ICANN. As subscribed, the countermeasures already exist
and how they are effective depend on how domain name registries
utilize these countermeasures in their IDN registration services
considering the balance between the usability and constraints of IDNs.

--------------------------------------------------------------------
Existing Countermeasures Applied to IDN Registration by Domain Name
Registries
--------------------------------------------------------------------
As stated above, this problem had already been identified, and the
following guidelines were already published to solve it:

* JET Guidelines (RFC3743) ( http://www.ietf.org/rfc/rfc3743.txt)

  Guidelines for IDN registration. They request registries to define
  languages to be registered as IDNs; define character code points
  allowed in IDNs; define variants (if any) to each character; and tag
  a language name to each IDN at registration to exclude inappropriate
  characters. These guidelines are defined along with table formats
  and algorithms.

* ICANN Guidelines ( http://www.icann.org/general/idn-guidelines-20jun03.htm)

  Guidelines for the Implementation of IDNs by registries. They guide
  registries to follow the IDN technical standards; define allowed
  character code points; associate a single language to each IDN;
  cooperate with relevant and interested stakeholders to develop
  language-specific registration policies, etc.

If each registry follows these guidelines in defining their IDN
registration services, IDNs containing characters in two or more
languages are excluded, and this results in a situation where
possibility of visual illusion with similar-looking characters is
dramatically reduced. For example, if a TLD registry defines Cyril
character 'ａ' to be a variant of ASCII 'a' following these
guidelines, 'Paypａl' is regarded as identical to 'paypal' under the
TLD.

Most of the registries currently providing IDN registration follow
these guidelines or plan to do so. As a result, phishing with
similar-looking IDNs with IDN-aware browsers is extremely suppressed.

--------------------------------------------------------------------
Measures Already Taken in Japanese .JP domain Name Registration from
Its Beginning
--------------------------------------------------------------------
Only Kanji, Hiragana, Katakana, and LDH, which all are usually used in
Japan, are allowed to be used in Japanese JP domain name. Characters
that are visually similar to ASCII alphabets, i.e., Cyrillic character
'ａ', is not allowed; and thus IDNs that are similar-looking to ASCII
domain names do not exist under .JP TLD. For example, 'Paypａl.jp'
cannot be registered and cannot be used as the site for phishing.

Furthermore, it is generally thought that, for the people who are
familiar with Japanese strings and unfamiliar with English spelling,
less visual illusion happens in Japanese character strings than in
English alphabet-only strings.

Therefore, it will hardly happen in Japanese JP domain name that
ill-willed websites use domain names with characters visually similar
to those used in existing ASCII domain names.

The above-mentioned countermeasures have been applied to Japanese JP
domain name from the start of its registration. On the other hand, the
problem tend to take place more easily in services carried out by the
registries not following the guidelines listed above.

In summary, the problem is rooted in IDN registration policies of each
registry, but not in IDN-aware applications such as browsers. Japanese
JP domain name, introduced taking into consideration of the above
possible problems, can be used without too much worry.
--------------------------------------------------------------------