Dear working group, Open-Xchange, as the maker of widely used email and DNS server software, would like to submit the following comment to the draft IDN guidelines. Open-Xchange is committed to a diverse and global Internet where all languages and scripts can be used easily. To this vision, the support and universal acceptance for Unicode domain names (IDNs) and email addresses (EAIs) is crucial. Unfortunately, efforts to promote this acceptance, including those fostered by ICANN itself, are often hampered by the misuse of IDNs for fraud and phishing. Just very recently, many news sources reprised a security advice that directed users to disable the display of IDN URLs in browsers, to prevent phishing by using whole-script confusable domain names: https://www.wordfence.com/blog/2017/04/chrome-firefox-unicode-phishing/ If this kind of mindset prevailed, IDNs would start to be widely rejected throughout the Internet. It is thus an important responsibility by ICANN and the domain name industry to do whatever is possible to prevent these dangers. This can be done quite easily by establishing, as a basic principle, that any two domain names that look confusable to an average Internet user must be considered variants of the same domain name and must never be registered to different registrants. We would welcome the formal establishment of this principle as a cornerstone upon which the IDN guidelines have to be based. While confusability is by definition a subjective feature, there are technical standards (i.e. Unicode TR-39) which provide an implementable definition and algorithm for detecting confusable domain names. So there is really no excuse for not implementing these standards. Moreover, allowing the registration of confusable domain names is not just hampering adoption of IDNs, but it is also creating significant financial and organizational costs to the rest of the Internet. Even before any successful phishing attack happens, software developers and Internet service providers dealing with all sorts of Internet applications are forced to take into account possible homoglyph attacks and implement countermeasures. It is much more efficient to detect and stop these situations just once at the registry level, rather than have the entire Internet run around in circles to deal with them. This is why we request to change point 16 of the proposed draft, and to make the detection and blocking of whole-script confusables compulsory. The first sentence of point 16 should thus be replaced by the following: "TLD registries must apply to new registrations whole label evaluation rules that minimize whole-script confusables as determined by Unicode Technical Standard #39: Unicode Security Mechanisms; new domain names that according to those rules are whole-script confusables in respect to an existing domain name must be a) allocated to the same registrant of the existing domain name, or b) blocked from registration." Kind regards, -- Vittorio Bertola Research & Innovation Engineer Cell: +39 348 7015022 Skype: in-skype-ox@bertola.eu Email: vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com Twitter: @openexchange http://twitter.com/openexchange - Facebook: OpenXchange https://www.facebook.com/OpenXchange - Web: www.open-xchange.com http://www.open-xchange.com Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Uwe Reumuth Chairman of the Board: Richard Seibt European Office: Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718 Managing Directors: Frank Hoberg, Martin Kauss US Office: Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system.
