[UA-discuss] IDN Implementation Guidelines [RE: Re : And now about phishing...]

siavash at dotbazaar.net siavash at dotbazaar.net
Sat Apr 22 06:04:12 UTC 2017


Hi Edmon,
Looks like there's a confusion in your message about recommendations 17 
and 9 of IDN Guidelines. The "may-must" dichotomy you're referring to 
occurs in item 9, not 17. Recomm 17 is OK as it stands, and I think you 
concur. Regarding 9, I take the opposite view from yours (expressed on 
another list). I believe we MUST stop ICANN from issuing unnecessary 
`musts' regarding second-level IDNs, or pretty soon we'll have to 
contend with ICANN working groups and task forces issuing best practice 
guidelines for third-level and fourth-level IDNs stifling the whole 
process. Imagine what would have happened to ASCII domains and domain 
industry had the same nit-picking occurred in 1990s or earlier. 
Sometimes I wonder if we're working for the Universal Acceptance of IDNs 
or trying to kill the baby before it's born.
Siavash

On 2017-04-21 14:45, Edmon Chung wrote:
> Starting a separate thread to focus on the IDN Implementation
> Guidelines Discussion.
> 
> For the Draft IDN Guidelines you pointed to, please do submit your
> comments into the still open public comments period (recently
> extended):
> 
> https://www.icann.org/public-comments/idn-guidelines-2017-03-03-en [1]
> 
> To the specific issue of wholescript confusables, there is a further
> explanation in point 17 why the current recommendation is a "may"
> rather than a "must"... But if we feel strongly it should move to a
> must, please do submit your comments in.
> 
> As for our work at UASG, I feel that it is probably a good idea to
> collect the counter arguments.
> 
> I recall there was a phishing/security report a couple years ago that
> highlighted the issue and indicated that while this (used to be
> "paypal" example), is possible it is hardly an issue statistically. 
> Does anyone have that report/link?
> 
> Edmon
> 
> FROM: ua-discuss-bounces at icann.org
> [mailto:ua-discuss-bounces at icann.org] ON BEHALF OF Vittorio Bertola
> SENT: Friday, 21 April 2017 17:04 PM
> TO: ua-discuss at icann.org; Asmus Freytag <asmusf at ix.netcom.com>
> SUBJECT: Re: [UA-discuss] Re : And now about phishing...
> 
> Il 21 aprile 2017 alle 0.52 Asmus Freytag <asmusf at ix.netcom.com> ha 
> scritto:
> 
> If you think about it, the following recommendation at the end is 
> anathema to "Universal acceptance":
> 
> "Zheng is encouraging Firefox users to limit their exposure to the bug 
> by going to the browser’s about:config settings and setting 
> network.IDN_show_punycode to true. By doing this Firefox will always 
> display IDN domains in its Punycode form, something that should make it 
> easier to identify malicious domains, the researcher claims."
> 
> If you do that, you implicitly assume that only the "non-IDN" links are 
> "real", in other words, you assume an English-only environment. (When 
> stuff is displayed as punicode, you usually can't tell what domain it 
> is, except you can guess for some European ones with very few special 
> characters, but you can't be sure unless the Unicode form is at least 
> also displayed, which I think is not what that config change means).
> 
> Hello,
> 
> excuse me if I jump into a discussion having just joined the list, but
> this issue is really troubling me for at least two reasons.
> 
> First, many news sources are now filling up with calls and guides for
> disabling IDNs in browsers altogether, which is a death call for
> universal acceptance. It all started with this horrible post by
> Wordfence's CEO, basically equating IDNs to an instrument conceived
> for phishing:
> 
> https://www.wordfence.com/blog/2017/04/chrome-firefox-unicode-phishing/ 
> [2]
> 
> It would be really good if anyone knew him and could have a chat with
> him, maybe even convince him to help spreading a better view of the
> issue.
> 
> Secondly, browser makers are now reacting in opposite ways:
> 
> 1) Microsoft's browser (AFAIK) will enable or disable the display of
> Unicode in the URL bar depending on the operating system's language;
> 
> 2) Google's browser, with a newly released patch, will not display
> Unicode IDNs in ASCII TLDs if the IDNs are whole-script confusables (
> https://codereview.chromium.org/2683793010 [3] );
> 
> 3) Mozilla's browser will explicitly always display Unicode IDNs
> regardless of whether this may be used for phishing (
> https://wiki.mozilla.org/IDN_Display_Algorithm_FAQ [4]and
> https://bugzilla.mozilla.org/show_bug.cgi?id=1332714 [5] ). However,
> multiple online sources are now advising people to use a Firefox
> configuration option that allows to disable the display of IDNs
> altogether.
> 
> (Don't know about Apple, Opera and others.)
> 
> As you see, this is going to hamper the usability of IDNs in URLs and,
> even worse, make it entirely unpredictable, depending on the user's
> browser choice.
> 
> The only real solution to this is that all registries treat whole
> script confusables as variants, so that they cannot be registered to
> anyone different than the owner of the equivalent ASCII domain.
> Unicode TR-39 allows to do this programmatically. However, I just
> checked the proposed draft IDN guidelines that are currently
> undergoing public consultation at ICANN:
> 
> https://www.icann.org/en/system/files/files/draft-idn-guidelines-03mar17-en.pdf
> [6]
> 
> At point 16, they say that the registry "may" do this, but that should
> really be a "must". If this does not happen, there will be more of
> these situations and the risk that all the Western world will then
> disable IDNs in URLs for good is quite significant.
> 
> I think that this group could do several useful things:
> 
> a) promote a better public understanding of the issue, countering the
> trend that "IDN URLs are for phishing";
> 
> b) encourage browser makers to elaborate a common approach;
> 
> c) push for ICANN and the registries to free the Internet from
> whole-script confusables.
> 
> Regards,
> 
> --
> 
> VITTORIO BERTOLA
> Research & Innovation Engineer
> 
> Cell:
> 
> +39 348 7015022
> 
> Skype:
> 
> in-skype-ox at bertola.eu
> 
> Email:
> 
> vittorio.bertola at open-xchange.com
> 


> Twitter: @openexchange [7] - Facebook: OpenXchange [8] - Web:
> www.open-xchange.com [9]
> 
> 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.
> 
> 
> 
> Links:
> ------
> [1] https://www.icann.org/public-comments/idn-guidelines-2017-03-03-en
> [2] 
> https://www.wordfence.com/blog/2017/04/chrome-firefox-unicode-phishing/
> [3] https://codereview.chromium.org/2683793010
> [4] https://wiki.mozilla.org/IDN_Display_Algorithm_FAQ
> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1332714
> [6]
> https://www.icann.org/en/system/files/files/draft-idn-guidelines-03mar17-en.pdf
> [7] http://twitter.com/openexchange
> [8] https://www.facebook.com/OpenXchange
> [9] http://www.open-xchange.com


More information about the UA-discuss mailing list