- comments-idn-guidelines-03mar17@icann.org

[Comments-idn-guidelines-03mar17] Registries Stakeholder Group (RySG) comments on Internationalized Domain Name (IDN) Implementation Guidelines
by svg＠milathan.ltd May 2, 2017

May 2, 2017

Please find attached, in PDF format, the Registries Stakeholder Group (RySG) comments on Internationalized Domain Name (IDN) Implementation Guidelines. In the interest of time, the RySG did not conduct a formal vote on these comments. They were circulated and debated on our mailing list, with no member expressing opposition to their submission. Please do not hesitate to contact me or any member of the RySG Executive Committee should you have any questions. Best regards, Stéphane Van Gelder RySG Vice Chair (Policy)

1 0

[Comments-idn-guidelines-03mar17] Comments from the IAB on IDN Implementation Guidelines
by Suzanne Woolf May 1, 2017

May 1, 2017

The IAB welcomes the opportunity to comment on "Guidelines for the Implementation of Internationalized Domain Names" (https://www.icann.org/en/system/files/files/draft-idn-guidelines-03mar17-en… <https://www.icann.org/en/system/files/files/draft-idn-guidelines-03mar17-en…>) As a general observation, the IAB found this document to be a good step in support of the deployment of Internationalized Domain Names in TLDs. It promotes the use of IDNs while also supporting careful specification and conservative implementation of registry and registrar policy. A few specific comments follow: Section 1.1: This is worded so that the document relies upon RFC 2119 keywords ("must," "should") but it is not, strictly speaking, a protocol document. It might be helpful to clarify that this normative language defines what it means to comply with these guidelines, but can't by itself specify protocol compliance. Section 2.1: The clear statement of support for compliance with IDNA2008 standard as a target, while also supporting a clean transition from other specifications, also seems appropriately conservative. Section 2.2 and 2.3: These sections aknowledge implicitly that there isn't always a good answer, that sometimes various combinations of a language and a script, or of possible variants, are not fully compatible across all the options and the registry simply has to make a decision. It might be helpful to state as much explicitly. Sec. 2.4, subsection 13, final paragraph: this is a sentence fragment, and not entirely clear. Is it meant as an example of the references appropriate for review to meet the guideline in the previous paragraphs for registry-side processing for IDN variants? Overall, Sec. 2.2-2.5 seem to provide a reasonable balance between clear guidance and discretion for TLDs trying to form IDN policies that support their user communities. Sec. 2.2-2.5 in the document seems to be trying to operationalize the provisions in RFC 5894 that registries have a policy and that they allow only those characters whose use they fully understand, but without quite stating that as the goal. A few words clarifying that point might help both ICANN and TLD operators in cases where it's not entirely clear how best to follow the guidelines. Respectfully submitted, Suzanne Woolf for the IAB

1 0

[Comments-idn-guidelines-03mar17] FW: [Ext] Comments from India-Internationalized Domain Name (IDN) Implementation Guidelines
by Sarmad Hussain May 1, 2017

May 1, 2017

Comments received from Govt. of India. Regards, Sarmad Hussain From: tsantosh(a)meity.gov.in [mailto:tsantosh@meity.gov.in] Sent: Monday, May 01, 2017 11:13 AM To: Sarmad Hussain <sarmad.hussain(a)icann.org> Cc: JS DeitY Rajiv Bansal; Pradeep Kumar Verma; Harish Chowdhary; shubham nixi Subject: [Ext] Comments from India-Internationalized Domain Name (IDN) Implementation Guidelines Dear Mr. Sarmad, Please find below the comments from India on Internationalized Domain Name (IDN) Implementation Guidelines https://www.icann.org/public-comments/idn-guidelines-2017-03-03-en For a diverse and global Internet where all languages and scripts can be used easily the universal acceptance for Unicode domain names (IDNs) and email addresses (EAIs) is crucial.The following are suggested. I. promote a better public understanding of the issue, countering the trend that "IDN URLs are for phishing" Rationale i. Efforts to promote universal acceptance, to stop the misuse of IDNs for fraud and phishing is essential. 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/) ii. Due to the point mentioned above, IDNs would start to be widely rejected throughout the Internet. It is thus an important responsibility by ICANN to prevent these dangers. II. To free the Internet from whole-script confusables (Similar characters in diffrenet scripts) iii. To establish, 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. i. As 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.It is advisable to implement these standards in the proposed guidelines. iv. In addition to that, 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 (look-a-like characters) 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. v. To the specific issue of whole script confusables, point 17 of the current recommendation is a "may" rather than a "must". But if we feel that it should move to a must. Replacing “may” to must will help to stop registration of the domains like "g00gle.com", to put blocks on cyber-squatting. vi. In 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. III. To deal with Emojis i. There should be separate guidelines to deal with EMOJIS. E.g. https://❤❤❤.ws/ -- Warm Regards T.Santhosh Scientist 'E' / Additional Director Ministry of Electronics and Information Technology Government of India Electronics Niketan, 6 CGO Complex, New Delhi - 110003 (India) Tel: +91-11-24364741, 24301831

1 0

[Comments-idn-guidelines-03mar17] Open-Xchange comment on draft IDN guidelines
by Vittorio Bertola April 24, 2017

April 24, 2017

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(a)bertola.eu Email: vittorio.bertola(a)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.

1 0

Not authoritative IDN labels inside a zone
by Hugo Salgado-Hernández March 8, 2017

March 8, 2017

Dear IDNG WG. I've read the "Guidelines for the Implementation of Internationalized Domain Names - Final Draft for the Public Comment – 3 March 2017" document, and have a comment. I've always missed a clarification regarding the use of IDN labels inside a TLD zone for records that are not-authoritative, like NS names and glue records. A TLD can pose rules and restrictions for labels in the second (or third) level, but not downside and "sibling-side". So my TLD can restrict a certain unicode point for registration purposes, but it could exist inside the TLD zone as an NS name in a level below the TLD as a glue record, and can exist at another TLD as a delegation, over which we don't have any jurisdiction. As an example, if I'm the registry of ".example" TLD and we don't allow "U+00E1 LATIN SMALL LETTER A WITH ACUTE", we can't prohibit a record like: allowed.example. IN NS á.allowed.example á.allowed.example. IN A 192.0.2.1 and certainly we can't prohibit a delegation to other TLD: allowed.example. IN NS á.cl I know this is common sense, but I've found people implementing IDN with this kind of doubts. I'll be very careful to clarify that "labels inside a zone" should meant "labels of authoritative names inside a zone". And maybe add a new guideline of the sort: "a TLD can't restrict the codepoints of names inside its zone for which it's not authoritative (such as delegations to sibling zones or glue records names), but should check such labels are syntactically valid U-labels (in RFC7940 sense)". Best regards, Hugo Salgado NIC Chile - .CL

1 0