On 4/19/2017 6:11 AM, Tan Tanaka, Dennis via UA-discuss wrote:

The thing with homoglyphs is that it depends on the choice of font type and size. That’s why it is hard to define the set. For example, in certain font types lower case L ‘l’ and number one ‘1’ (both ASCII) look almost identical.

For this reason, I like to distinguish between true homoglyphs (identical or near identical appearance by design or across the range of typical UI fonts) on the one hand, and 'merely' similar code points on the other. In its most general incarnation, similarity can be accidental. For example "rn" and "m" are harder to distinguish that one might think. This general issue needs to be addressed, but it involves a lot of subjectivity. It also involves cases where of three similar items, one pair may appear distinct, while two other pairs are not. (For a true homograph, the homograph relation should be transitive).

To deal with cases of cross-script homoglyphs, the ICANN IDN guidelines have a requirement to prohibited such registrations (i.e. mixing Cyrillic with Latin in a single label) except for in cases of established orthographies, such as Japanese (i.e. Japanese uses three different scripts: Han, Hiragana and Katakana).

The prohibition on script mixing in a single label is useful for a number of cases, but doesn't cover anywhere near the full scope of the problem. Many scripts have an "o". Disallowing script mixing makes sure that one cannot spoof a label containing an "o", by substituting an "o" from another script. So far, so good. However, the labels "ooo", "oooo" and so on are not protected. Writing the whole label in the other script makes it 'legal', but it can still be used for spoofing. When this only affects a handful of labels (how many strings consisting entirely of "o" will be registered?) the benefit of a general solution is likewise limited. The problem is those scripts that more than one code point like that. E.g. "p", "e", "s" etc. exist in equivalent shapes in both Latin and Cyrillic. Many more labels are thus subject to a whole-label homograph attack, and the prohibition against script mixing doesn't help. A more robust approach is to make cross-script homoglyphs blocked variants of each other. This ensures that look-alike strings become mutually exclusive: only one can be delegated. (Note, by the way, that the reduction of available labels is not as big as it might appear: most labels would contain at least one script-unique letter, making it secure from a homograph attack like that). For a discussion of variants, read: https://datatracker.ietf.org/doc/draft-freytag-lager-variant-rules/ A./

-Dennis

*From: *<ua-discuss-bounces@icann.org> on behalf of deepak <deepak.singhal@dil.in> *Date: *Wednesday, April 19, 2017 at 1:33 AM *To: *Dusan Stojicevic <dusan@dukes.in.rs>, "UA-discuss@icann.org" <ua-discuss@icann.org> *Subject: *[EXTERNAL] [UA-discuss] Re : And now about phishing...

Hi,

These are homoglyph character http://homoglyphs.net/ which can be use in phishing ..

Regards Deepak Singhal

------------------------------------------------------------------------

*From:* "Dusan Stojicevic" <dusan@dukes.in.rs> MailId : [68261406] *To:* "ua-discuss" <UA-discuss@icann.org> *Subject: *[UA-discuss] And now about phishing... *Date:* 19 Apr 2017 12:24:34 AM

Interesting and possible>

https://www.wordfence.com/blog/2017/04/chrome-firefox-unicode-phishing/

Cheers,

Dusan

mage removed by sender. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...>

Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...>

Do not Remove: [HID]20170419002433157[-HID]

[XGENFOOTER]

[-XGENFOOTER]

More on the issue… any comments? Someone from Google here? https://threatpost.com/google-fixes-unicode-phishing-vulnerability-in-chrome... Cheers, Dusan From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Richard Merdinger Sent: Wednesday, April 19, 2017 11:15 PM To: Asmus Freytag <asmusf@ix.netcom.com>; ua-discuss@icann.org Subject: Re: [UA-discuss] Re : And now about phishing... Thank you for the thoughtful reply, Asmus. --Rich Richard Merdinger VP, Domains - GoDaddy From: <ua-discuss-bounces@icann.org <mailto:ua-discuss-bounces@icann.org> > on behalf of Asmus Freytag <asmusf@ix.netcom.com <mailto:asmusf@ix.netcom.com> > Date: Wednesday, April 19, 2017 at 3:44 PM To: "ua-discuss@icann.org <mailto:ua-discuss@icann.org> " <ua-discuss@icann.org <mailto:ua-discuss@icann.org> > Subject: Re: [UA-discuss] Re : And now about phishing... On 4/19/2017 6:11 AM, Tan Tanaka, Dennis via UA-discuss wrote: The thing with homoglyphs is that it depends on the choice of font type and size. That’s why it is hard to define the set. For example, in certain font types lower case L ‘l’ and number one ‘1’ (both ASCII) look almost identical. For this reason, I like to distinguish between true homoglyphs (identical or near identical appearance by design or across the range of typical UI fonts) on the one hand, and 'merely' similar code points on the other. In its most general incarnation, similarity can be accidental. For example "rn" and "m" are harder to distinguish that one might think. This general issue needs to be addressed, but it involves a lot of subjectivity. It also involves cases where of three similar items, one pair may appear distinct, while two other pairs are not. (For a true homograph, the homograph relation should be transitive). To deal with cases of cross-script homoglyphs, the ICANN IDN guidelines have a requirement to prohibited such registrations (i.e. mixing Cyrillic with Latin in a single label) except for in cases of established orthographies, such as Japanese (i.e. Japanese uses three different scripts: Han, Hiragana and Katakana). The prohibition on script mixing in a single label is useful for a number of cases, but doesn't cover anywhere near the full scope of the problem. Many scripts have an "o". Disallowing script mixing makes sure that one cannot spoof a label containing an "o", by substituting an "o" from another script. So far, so good. However, the labels "ooo", "oooo" and so on are not protected. Writing the whole label in the other script makes it 'legal', but it can still be used for spoofing. When this only affects a handful of labels (how many strings consisting entirely of "o" will be registered?) the benefit of a general solution is likewise limited. The problem is those scripts that more than one code point like that. E.g. "p", "e", "s" etc. exist in equivalent shapes in both Latin and Cyrillic. Many more labels are thus subject to a whole-label homograph attack, and the prohibition against script mixing doesn't help. A more robust approach is to make cross-script homoglyphs blocked variants of each other. This ensures that look-alike strings become mutually exclusive: only one can be delegated. (Note, by the way, that the reduction of available labels is not as big as it might appear: most labels would contain at least one script-unique letter, making it secure from a homograph attack like that). For a discussion of variants, read: https://datatracker.ietf.org/doc/draft-freytag-lager-variant-rules/ A./ -Dennis From: <mailto:ua-discuss-bounces@icann.org> <ua-discuss-bounces@icann.org> on behalf of deepak <mailto:deepak.singhal@dil.in> <deepak.singhal@dil.in> Date: Wednesday, April 19, 2017 at 1:33 AM To: Dusan Stojicevic <mailto:dusan@dukes.in.rs> <dusan@dukes.in.rs>, <mailto:UA-discuss@icann.org> "UA-discuss@icann.org" <mailto:ua-discuss@icann.org> <ua-discuss@icann.org> Subject: [EXTERNAL] [UA-discuss] Re : And now about phishing... Hi, These are homoglyph character http://homoglyphs.net/ which can be use in phishing .. Regards Deepak Singhal _____ From: "Dusan Stojicevic" <mailto:dusan@dukes.in.rs> <dusan@dukes.in.rs> MailId : [68261406] To: "ua-discuss" <mailto:UA-discuss@icann.org> <UA-discuss@icann.org> Subject: [UA-discuss] And now about phishing... Date: 19 Apr 2017 12:24:34 AM Interesting and possible> https://www.wordfence.com/blog/2017/04/chrome-firefox-unicode-phishing/ Cheers, Dusan <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...> Virus-free. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...> www.avast.com Do not Remove: [HID]20170419002433157[-HID] [XGENFOOTER] [-XGENFOOTER] --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

On 4/20/2017 3:24 PM, Dusan Stojicevic wrote:

More on the issue… any comments? Someone from Google here?

https://threatpost.com/google-fixes-unicode-phishing-vulnerability-in-chrome...

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). A./

Cheers,

Dusan

*From:*ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] *On Behalf Of *Richard Merdinger *Sent:* Wednesday, April 19, 2017 11:15 PM *To:* Asmus Freytag <asmusf@ix.netcom.com>; ua-discuss@icann.org *Subject:* Re: [UA-discuss] Re : And now about phishing...

Thank you for the thoughtful reply, Asmus.

--Rich

Richard Merdinger

VP, Domains - GoDaddy

*From: *<ua-discuss-bounces@icann.org <mailto:ua-discuss-bounces@icann.org>> on behalf of Asmus Freytag <asmusf@ix.netcom.com <mailto:asmusf@ix.netcom.com>> *Date: *Wednesday, April 19, 2017 at 3:44 PM *To: *"ua-discuss@icann.org <mailto:ua-discuss@icann.org>" <ua-discuss@icann.org <mailto:ua-discuss@icann.org>> *Subject: *Re: [UA-discuss] Re : And now about phishing...

On 4/19/2017 6:11 AM, Tan Tanaka, Dennis via UA-discuss wrote:

The thing with homoglyphs is that it depends on the choice of font type and size. That’s why it is hard to define the set. For example, in certain font types lower case L ‘l’ and number one ‘1’ (both ASCII) look almost identical.

For this reason, I like to distinguish between true homoglyphs (identical or near identical appearance by design or across the range of typical UI fonts) on the one hand, and 'merely' similar code points on the other.

In its most general incarnation, similarity can be accidental. For example "rn" and "m" are harder to distinguish that one might think. This general issue needs to be addressed, but it involves a lot of subjectivity. It also involves cases where of three similar items, one pair may appear distinct, while two other pairs are not. (For a true homograph, the homograph relation should be transitive).

To deal with cases of cross-script homoglyphs, the ICANN IDN guidelines have a requirement to prohibited such registrations (i.e. mixing Cyrillic with Latin in a single label) except for in cases of established orthographies, such as Japanese (i.e. Japanese uses three different scripts: Han, Hiragana and Katakana).

The prohibition on script mixing in a single label is useful for a number of cases, but doesn't cover anywhere near the full scope of the problem.

Many scripts have an "o". Disallowing script mixing makes sure that one cannot spoof a label containing an "o", by substituting an "o" from another script. So far, so good.

However, the labels "ooo", "oooo" and so on are not protected. Writing the whole label in the other script makes it 'legal', but it can still be used for spoofing.

When this only affects a handful of labels (how many strings consisting entirely of "o" will be registered?) the benefit of a general solution is likewise limited. The problem is those scripts that more than one code point like that. E.g. "p", "e", "s" etc. exist in equivalent shapes in both Latin and Cyrillic. Many more labels are thus subject to a whole-label homograph attack, and the prohibition against script mixing doesn't help.

A more robust approach is to make cross-script homoglyphs blocked variants of each other. This ensures that look-alike strings become mutually exclusive: only one can be delegated. (Note, by the way, that the reduction of available labels is not as big as it might appear: most labels would contain at least one script-unique letter, making it secure from a homograph attack like that).

For a discussion of variants, read: https://datatracker.ietf.org/doc/draft-freytag-lager-variant-rules/

A./

-Dennis

*From: *<ua-discuss-bounces@icann.org> <mailto:ua-discuss-bounces@icann.org> on behalf of deepak <deepak.singhal@dil.in> <mailto:deepak.singhal@dil.in> *Date: *Wednesday, April 19, 2017 at 1:33 AM *To: *Dusan Stojicevic <dusan@dukes.in.rs> <mailto:dusan@dukes.in.rs>, "UA-discuss@icann.org" <mailto:UA-discuss@icann.org> <ua-discuss@icann.org> <mailto:ua-discuss@icann.org> *Subject: *[EXTERNAL] [UA-discuss] Re : And now about phishing...

Hi,

These are homoglyph character http://homoglyphs.net/ which can be use in phishing ..

Regards Deepak Singhal

------------------------------------------------------------------------

*From:* "Dusan Stojicevic" <dusan@dukes.in.rs> <mailto:dusan@dukes.in.rs> MailId : [68261406] *To:* "ua-discuss" <UA-discuss@icann.org> <mailto:UA-discuss@icann.org> *Subject: *[UA-discuss] And now about phishing... *Date:* 19 Apr 2017 12:24:34 AM

Interesting and possible>

https://www.wordfence.com/blog/2017/04/chrome-firefox-unicode-phishing/

Cheers,

Dusan

age removed by sender. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...>

Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...>

Do not Remove: [HID]20170419002433157[-HID]

[XGENFOOTER]

[-XGENFOOTER]

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...>

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

More on Mozilla> https://wiki.mozilla.org/IDN_Display_Algorithm FWIW, I think that this is a problem on which UASG must react somehow. @Asmus: this phishing issue is not new. We were speaking about it 2 years ago. And yes, it’s starting to create a big problem. Cheers, Dusan From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Vittorio Bertola Sent: Friday, April 21, 2017 11:04 AM To: ua-discuss@icann.org; Asmus Freytag <asmusf@ix.netcom.com> Subject: Re: [UA-discuss] Re : And now about phishing... Il 21 aprile 2017 alle 0.52 Asmus Freytag <asmusf@ix.netcom.com <mailto:asmusf@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 <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.... 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@bertola.eu <mailto: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. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Hi Asmus, If I understood correctly, it’s a good approach, but it’s definitely not the one for average user. First of all, average user have a problem to see the difference between http and https. Average owner of domain name usually don’t know what SSL is. I agree with you that this suggestion is better than make IDNs second-class URLs, but in my opinion, it’s not for average user. And in this case, you just assume that “fake websites” must have certificate? And yes, I admit, I don’t know how to solve this… Cheers, Dusan From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Asmus Freytag Sent: Friday, April 21, 2017 7:05 PM To: ua-discuss@icann.org Subject: Re: [UA-discuss] Re : And now about phishing... On 4/21/2017 2:50 AM, Dusan Stojicevic wrote: More on Mozilla> https://wiki.mozilla.org/IDN_Display_Algorithm FWIW, I think that this is a problem on which UASG must react somehow. @Asmus: this phishing issue is not new. We were speaking about it 2 years ago. And yes, it’s starting to create a big problem. All, confusables spoofing is *not* limited to cross-script homoglyphs, although the Latin/Cyrillic case is particularly egregious. This kind of defense shown below works even for non-homoglyph attacks, such as "gooogle" or similar typos that may be hard to spot with perfect reliability. More can be done in that direction, without making IDNs second-class URLs. For the cross script case, the registries could do a lot more, and we are definitely going to do more in the root. On my system I get this, when I connect to "apple.com": and this, for the "fake" (https://www.аррӏе.com/) Arguably, the lock should change color if there's no owner information present, to give a better warning than just the absence of an identification. A./ @Dusan: I know that this phishing issue is not new, I've known about that one for way longer than just two years (and for longer than I've been active in the IDN area). Cheers, Dusan From: ua-discuss-bounces@icann.org <mailto:ua-discuss-bounces@icann.org> [mailto:ua-discuss-bounces@icann.org] On Behalf Of Vittorio Bertola Sent: Friday, April 21, 2017 11:04 AM To: ua-discuss@icann.org <mailto:ua-discuss@icann.org> ; Asmus Freytag <mailto:asmusf@ix.netcom.com> <asmusf@ix.netcom.com> Subject: Re: [UA-discuss] Re : And now about phishing... Il 21 aprile 2017 alle 0.52 Asmus Freytag <asmusf@ix.netcom.com <mailto:asmusf@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 <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.... 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@bertola.eu <mailto: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. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...> Virus-free. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...> www.avast.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

On 4/21/2017 2:45 PM, Dusan Stojicevic wrote:

Hi Asmus,

If I understood correctly, it’s a good approach, but it’s definitely not the one for average user.

The average user will rely on the browser putting some kind of "OK" sign next to the URL. That's why I wrote that the lock symbol for https should be of some other color than green to alert the user that something might not be right when a site has a certificate but no information on ownership of that certificate. Also, unsecured connections should be flagged positively as such, not passively by the absence of some symbol.

First of all, average user have a problem to see the difference between http and https. Average owner of domain name usually don’t know what SSL is.

For this approach, you don't need to know what the browser bases its feedback on, only that it is consistent, can be relied upon and if you don't click unless the site shows the proper check mark (and the name, in clear text of the correct organization, e.g. Apple (US)). Those things users can understand. A./

I agree with you that this suggestion is better than make IDNs second-class URLs, but in my opinion, it’s not for average user.

And in this case, you just assume that “fake websites” must have certificate?

And yes, I admit, I don’t know how to solve this…

Cheers,

Dusan

*From:*ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] *On Behalf Of *Asmus Freytag *Sent:* Friday, April 21, 2017 7:05 PM *To:* ua-discuss@icann.org *Subject:* Re: [UA-discuss] Re : And now about phishing...

On 4/21/2017 2:50 AM, Dusan Stojicevic wrote:

More on Mozilla>

https://wiki.mozilla.org/IDN_Display_Algorithm

FWIW, I think that this is a problem on which UASG must react somehow.

@Asmus: this phishing issue is not new. We were speaking about it 2 years ago. And yes, it’s starting to create a big problem.

All,

confusables spoofing is *not* limited to cross-script homoglyphs, although the Latin/Cyrillic case is particularly egregious.

This kind of defense shown below works even for non-homoglyph attacks, such as "gooogle" or similar typos that may be hard to spot with perfect reliability. More can be done in that direction, without making IDNs second-class URLs.

For the cross script case, the registries could do a lot more, and we are definitely going to do more in the root.

On my system I get this, when I connect to "apple.com":

and this, for the "fake" (https://www.аррӏе.com/ <https://www.%D0%B0%D1%80%D1%80%D3%8F%D0%B5.com/>)

Arguably, the lock should change color if there's no owner information present, to give a better warning than just the absence of an identification.

A./

@Dusan: I know that this phishing issue is not new, I've known about that one for way longer than just two years (and for longer than I've been active in the IDN area).

Cheers, Dusan

*From:*ua-discuss-bounces@icann.org <mailto:ua-discuss-bounces@icann.org> [mailto:ua-discuss-bounces@icann.org] *On Behalf Of *Vittorio Bertola *Sent:* Friday, April 21, 2017 11:04 AM *To:* ua-discuss@icann.org <mailto:ua-discuss@icann.org>; Asmus Freytag <asmusf@ix.netcom.com> <mailto:asmusf@ix.netcom.com> *Subject:* Re: [UA-discuss] Re : And now about phishing...

Il 21 aprile 2017 alle 0.52 Asmus Freytag <asmusf@ix.netcom.com <mailto:asmusf@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....

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@bertola.eu <mailto: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.

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...>

Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...>

Vittorio, You bring up a great point. The TLD registry policies are as important as the browsers. And we should certainly reach out to them. Don/CommsTeam, Is Edelman on the case already? Edmon From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Vittorio Bertola Sent: Friday, 21 April 2017 17:04 PM To: ua-discuss@icann.org; Asmus Freytag <asmusf@ix.netcom.com> Subject: Re: [UA-discuss] Re : And now about phishing... Il 21 aprile 2017 alle 0.52 Asmus Freytag <asmusf@ix.netcom.com <mailto:asmusf@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 <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.... 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@bertola.eu <mailto: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.

Colleagues, Gwen and I had a briefing on this subject with Edelman. They are actively monitoring the subject, and developing a short-term and medium-term strategy to mitigate it. They will have a blog post drafted and out to the UA comms group for review - to start us out in our response - later today. The Edelman team has been copied on this thread. All the best, Christian Dawson Executive Director Internet Infrastructure Coalition (i2C) c: 703 623 2612 http://i2coalition.com PGP: 22DF5493 Fingerprint: 7C95 A3BE 1E10 4864 8417 DCED B9E1 C8FD 22DF 5493

On Apr 21, 2017, at 7:27 AM, Christian Dawson <dawson@i2coalition.com> wrote:

Edmon,

I am briefing Edelman today and working on how we shift our focus to address this. More when I know it.

All the best,

Christian Dawson Executive Director Internet Infrastructure Coalition (i2C) c: 703 623 2612 http://i2coalition.com

PGP: 22DF5493 Fingerprint: 7C95 A3BE 1E10 4864 8417 DCED B9E1 C8FD 22DF 5493

...

On Apr 21, 2017, at 6:00 AM, Edmon Chung <edmon@registry.asia> wrote:

Vittorio, You bring up a great point. The TLD registry policies are as important as the browsers. And we should certainly reach out to them.

Don/CommsTeam, Is Edelman on the case already?

Edmon

From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Vittorio Bertola Sent: Friday, 21 April 2017 17:04 PM To: ua-discuss@icann.org; Asmus Freytag <asmusf@ix.netcom.com> Subject: Re: [UA-discuss] Re : And now about phishing...

Il 21 aprile 2017 alle 0.52 Asmus Freytag <asmusf@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....

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@bertola.eu Email: vittorio.bertola@open-xchange.com

Twitter: @openexchange - Facebook: OpenXchange - Web: www.open-xchange.com <image001.png> 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.