Anti-phishing Working Group comments

["Mike Rodenbaugh" <mxrodenbaugh@xxxxxxxxx>]

IDNs and Phishing

 

Different characters in different scripts can look similar, especially
depending on the font used.   IDNs therefore provide additional options to
create a spoofed Web site with a URL that looks much like (or even exactly
like) another, and can therefore be very useful for phishing.  Also, the
multi-lingual nature of IDNs present unique challenges for parties who
conduct anti-phishing work.  The APWG recommends the following in response
to ICANN's request for public comment with respect to introduction of IDN
ccTLDs -- http://www.icann.org/announcements/announcement-19dec07.htm.

 

Follow IDN Standards

 

Registries should follow:

1.      The Internationalizing Domain Names in Applications (IDNA) standard.

2.      The ICANN Guidelines for the Implementation of Internationalized
Domain Names < http://www.icann.org/general/idn-guidelines-20jun03.htm >.
By following the guidelines, registries will:

..         Deploy variant solutions and limit the character sets allowed,
thereby reducing opportunities for spoofing and homographic attacks. 

..         Publish language tables and language-specific registration rules.

..         Avoid mixing characters from different scripts in the same domain
name.

 

WHOIS

 

WHOIS allows the public and anti-phishing parties to reference registration
information, contact domain owners, and discover problematic domain names.
Registries should publish WHOIS information for IDNs that includes clearly
labeled fields for the following:

1.      the punicode version of the domain name (beginning with "xn--"),
2.      the unicode version of the domain name, and
3.      an HTML version that shows the domain rendered in its
native-character form.

 

Otherwise, it is helpful if WHOIS data fields continue to be served in ASCII
characters, rather than only in native characters or in unicode. This will
allow vital information such as e-mail addresses and nameserver information
to be displayed and understood to the widest audience.  Two examples of
preferred WHOIS output are:  xn--motorradbrse-djb.org (at www.pir.org), and
xn--kinderbcher-zhb.info (at www.afilias.info).

 

Dispute Resolution

 

Registries, registrars, and ICANN should ensure that their dispute
resolution policies address IDN-specific problems.  Dispute resolution
providers should train their arbitrators regarding IDN issues, and assign
arbitrators that have expertise in the relevant language(s) involved in a
given dispute case.

 

Top-Level IDNs

 

A more recent topic of interest is the creation of IDN Top Level Domains
(IDN.IDN, or IDN TLDs).  These will allow the entire domain name to be
represented in a local language character set, including the TLD label.
Technical tests are being conducted by ICANN to ensure feasibility, and
policy issues are being discussed.  

 

The right to run top-level IDNs should be assigned carefully by ICANN.  We
strongly agree with the GNSO's recommendation to the ICANN Board, that TLDs
confusingly similar to existing TLDs shall be prohibited. (See
Recommendation 2,
http://gnso.icann.org/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm.)
Confusingly similar TLDs assist phishers by enabling them to more easily
confuse users visually with a phishing URL, and could create confusion even
as to the appropriate registry to query WHOIS.  

 

Submitted by Mike Rodenbaugh and Greg Aaron of the APWG Internet Policy
Committee