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

Fri Apr 21 17:11:00 UTC 2017

Thanks Nalini,

Share that view, and yes, it was small number when we spoke two years ago.
Besides paypal, apple, epic, there is as much brands as you want, which can be made from just Cyrillic chars: Coca-cola, Pepsi, Opel, IBM... 
And these are just brand names with Cyrillic... more of them can be made with other scripts (Armenian, Georgian, Greek, Arabic...).
Also agree entirely with Vittorio, and just want to add another layer of the problem - epic.com example use https, and while GeoTrust and at least one other CA have stopped issuing automated certificated for IDNs sometime ago for other reasons, this trend will be expected for others to follow.
So, we need to address this issue and try to explain also to end users what is this (f.e. there is one explanation, which is not entirely ok: https://en.wikipedia.org/wiki/IDN_homograph_attack).

Cheers, 
Dusan

-----Original Message-----
From: ua-discuss-bounces at icann.org [mailto:ua-discuss-bounces at icann.org] On Behalf Of nalini.elkins at insidethestack.com
Sent: Friday, April 21, 2017 4:12 PM
To: 'Vittorio Bertola' <vittorio.bertola at open-xchange.com>; ua-discuss at icann.org; 'Asmus Freytag' <asmusf at ix.netcom.com>; Edmon Chung <edmon at registry.asia>
Subject: Re: [UA-discuss] IDN Implementation Guidelines [RE: Re : And now about phishing...]

Edmon,

> it is hardly an issue statistically   

I am certainly in agreement in not living in a fact-free world.  So, I am collecting data on such sites.   I am in the process of setting up a server to monitor 24 x 7 with a homographic domain finder product that we have written. 

I can tell you from my initial testing that there are a surprising number.   Currently, they appear to be for domains which are known world-wide.

More as it happens...

Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

--------------------------------------------
On Fri, 4/21/17, Edmon Chung <edmon at registry.asia> wrote:

 Subject: [UA-discuss] IDN Implementation Guidelines [RE: Re : And now about	phishing...]
 To: "'Vittorio Bertola'" <vittorio.bertola at open-xchange.com>, ua-discuss at icann.org, "'Asmus Freytag'" <asmusf at ix.netcom.com>
 Date: Friday, April 21, 2017, 3:15 AM

 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
  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/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) 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
 and https://bugzilla.mozilla.org/show_bug.cgi?id=1332714
 ). 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.pdfAt
 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 7015022Skype:in-skype-ox at bertola.euEmail:vittorio.bertola at open-xchange.com
   Twitter: @openexchange -
 Facebook: OpenXchange
 - Web: www.open-xchange.comOpen-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.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus