Recently a proof of concept attack was announced on the Internet that demonstrated how a web address could be constructed that looked in some web browsers identical to that of a well known website. This technique could be used to trick a user into going to a website that they did not plan on visiting, and possibly provide sensitive information to a third party.

As a result of this demonstration, there has been a number of voices calling for web browsers to disable or remove support for IDNs by default. For example, on 15 February 2005 the Mozilla Foundation announced it had a plan to disable IDNs by default in future versions of its web browsers.

CENTR, a group of many of the world’s domain registries - representing over 98% of domain registrations worldwide - believes such strong reactions are heavily detrimental to the effort to introduce non-English languages and scripts to the Internet, and could have lasting repercussions on the ongoing effort to internationalise the DNS.

With this in mind, CENTR would like to make the following points:

• The largest hurdle in deploying IDNs is ensuring there is a critical mass of users who have support for the technology. Browsers which have IDNs disabled by default and require extra steps to enable it will result in most installers not turning on the feature. This will shrink the potential userbase of IDNs and harm efforts to internationalise the Internet.
• The specific attack has been well known for many years. It has been raised in most policy discussions that occurred leading up to IDN deployment, as well has being specifically identified in the IDN specification (The attack is documented in the “Security Considerations” section of the IDN standard. Ref. RFC 3490). It is not a surprise attack vector that requires a hasty ill-considered response by the community.
• The exploit relies on a specific mix of character sets that does not affect most TLD registries, as they have adopted policies that limit the ability to mix scripts. CENTR encourages registries to adopt appropriate policies for their user communities that weigh in the resulting security impact.
• Generally, homograph attacks are possible in regular domain registrations, and are not limited only to IDNs. For example, lower case “L” and upper case “i” look identical in the commonly used Arial font. Therefore, the same attack could be developed simply using the English alphabet. IDNs are being unfairly singled out for special treatment for a problem that exists in regular domain names.
• Software vendors should be cautious of the implications of software enforced domain naming policies on the entire global community, not just the impact on the English speaking world.

CENTR believes steps can be taken to lower the risk of homograph attacks, but need to be considered carefully. A rush to introducing IDN-disabled browsers into the market place, however, is an overly zealous step that will harm public confidence in IDNs - a technology that is desperately needed in the non-English speaking world.

More considered software approaches to the problem could include security warnings, in the same style as existing security warnings that exist for invalid SSL certificates or unsigned code. Such warnings could identify when there is a mix of “code pages” (such as Latin and Cyrillic) and give the user the option to proceed or decline.

It is important to note that mixing code pages in itself is not a security hazard, and is indeed a requirement for some locales. Therefore, such approaches should come with the ability to set a preference for allowing specific mixes of code pages in future.

We also would like to applaud efforts by the gTLD registries (ICANN gTLD Constituency Release, 23 February 2005) to further develop registration policies that will limit the risk for their constituencies. They have noted the importance of policies which are responsible to the global community, whilst remaining true to the promise of IDNs—allowing the world’s communities to communicate in their own native scripts.

CENTR looks forward to working constructively on these issues, and seeks to further engage with IDN deployers to help the community arrive at satisfactory outcomes. We have had promising exchanges with registries and developers on this issue, and would like to thank those who have taken a genuine interest in finding solutions which balance with the interests of the IDN community.