IDN Variants in the market place
Please take a look at the attached screenshot of a domainer's offer to sell single character IDNs, for instance an IDN variant (lookalike) of the ASCII character X, which sets a harmful trend. This is an issue if confusability. I understand that the Registries (are required to?) maintain a list of harmful names for their TLDs, but there is no common minimal list of harmful names. One possible way to achieve this is for the Registries, at least in the ASCII space, to volunteer to feed their respective list of harmful names into a common Registry Stakeholder database, and then draw up a common minimum list of harmful domain names that any Registry could avoid registering. If At-Large could shape this as a workable suggestion, it could formally go to the Registry Stakeholders. Sivasubramanian M
Thank you for sharing Hadia From: At-Large [mailto:at-large-bounces@atlarge-lists.icann.org] On Behalf Of Sivasubramanian M Sent: Thursday, July 19, 2018 12:19 PM To: At-Large Worldwide Cc: At-Large Staff Subject: [At-Large] IDN Variants in the market place Please take a look at the attached screenshot of a domainer's offer to sell single character IDNs, for instance an IDN variant (lookalike) of the ASCII character X, which sets a harmful trend. This is an issue if confusability. I understand that the Registries (are required to?) maintain a list of harmful names for their TLDs, but there is no common minimal list of harmful names. One possible way to achieve this is for the Registries, at least in the ASCII space, to volunteer to feed their respective list of harmful names into a common Registry Stakeholder database, and then draw up a common minimum list of harmful domain names that any Registry could avoid registering. If At-Large could shape this as a workable suggestion, it could formally go to the Registry Stakeholders. Sivasubramanian M
Which charset it is? Cyrillic or something else? чт, 19 июля 2018 г. в 13:21, Sivasubramanian M <6.Internet@gmail.com>:
Please take a look at the attached screenshot of a domainer's offer to sell single character IDNs, for instance an IDN variant (lookalike) of the ASCII character X, which sets a harmful trend. This is an issue if confusability.
I understand that the Registries (are required to?) maintain a list of harmful names for their TLDs, but there is no common minimal list of harmful names. One possible way to achieve this is for the Registries, at least in the ASCII space, to volunteer to feed their respective list of harmful names into a common Registry Stakeholder database, and then draw up a common minimum list of harmful domain names that any Registry could avoid registering.
If At-Large could shape this as a workable suggestion, it could formally go to the Registry Stakeholders.
Sivasubramanian M _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- -- {ak}
On July 19, 2018 at 15:48 6.Internet@gmail.com (Sivasubramanian M) wrote:
Please take a look at the attached screenshot of a domainer's offer to sell single character IDNs, for instance an IDN variant (lookalike) of the ASCII character X, which sets a harmful trend. This is an issue if confusability.
The general term for this is "homograph attack" or specifically "IDN homograph attack", where "attack" may be in the eye of the beholder: https://en.wikipedia.org/wiki/IDN_homograph_attack and has been the subject of much discussion over recent years and little resolution. I believe one popular proposal is browser support which either visually flags such IDNs or displays the punycode alongside which is an ASCII represenation and should make obvious that this not what one might suspect. For example (from this wikipedia page): xn--bcher-kva.tld indicating an umlauted 'u' is in there but importantly that it's not just bucher.tld. https://en.wikipedia.org/wiki/Punycode There's still the problem with intent. Could I legitimately offer for sale the strings with and without the umlaut? I think that's generally considered acceptable. Caveat emptor?
I understand that the Registries (are required to?) maintain a list of harmful names for their TLDs, but there is no common minimal list of harmful names. One possible way to achieve this is for the Registries, at least in the ASCII space, to volunteer to feed their respective list of harmful names into a common Registry Stakeholder database, and then draw up a common minimum list of harmful domain names that any Registry could avoid registering.
If At-Large could shape this as a workable suggestion, it could formally go to the Registry Stakeholders.
Sivasubramanian M x[DELETED ATTACHMENT Screenshot_20180719-152932~2.png, PNG image] _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
Barry, spot on, plus the idea of a list of forbidden strings appears to be pure lunacy in this context. All strings are potentially an attack for any substitution of any character by any IDN look-alike character. The list would contain a couple zillion names and as you say, many could be legtimate. To complicate things further, an ASCII "A" could be used in an homograph attack by substituting for a Greek or Cyrillic "A" as well. I may be missing something and would study a correction though. Alejandro Pisanty On Fri, Jul 20, 2018 at 1:37 PM, <bzs@theworld.com> wrote:
On July 19, 2018 at 15:48 6.Internet@gmail.com (Sivasubramanian M) wrote:
Please take a look at the attached screenshot of a domainer's offer to sell single character IDNs, for instance an IDN variant (lookalike) of the ASCII character X, which sets a harmful trend. This is an issue if confusability.
The general term for this is "homograph attack" or specifically "IDN homograph attack", where "attack" may be in the eye of the beholder:
https://en.wikipedia.org/wiki/IDN_homograph_attack
and has been the subject of much discussion over recent years and little resolution.
I believe one popular proposal is browser support which either visually flags such IDNs or displays the punycode alongside which is an ASCII represenation and should make obvious that this not what one might suspect.
For example (from this wikipedia page): xn--bcher-kva.tld indicating an umlauted 'u' is in there but importantly that it's not just bucher.tld.
https://en.wikipedia.org/wiki/Punycode
There's still the problem with intent. Could I legitimately offer for sale the strings with and without the umlaut? I think that's generally considered acceptable.
Caveat emptor?
I understand that the Registries (are required to?) maintain a list of
harmful
names for their TLDs, but there is no common minimal list of harmful names. One possible way to achieve this is for the Registries, at least in the ASCII space, to volunteer to feed their respective list of harmful names into a common Registry Stakeholder database, and then draw up a common minimum list of harmful domain names that any Registry could avoid registering.
If At-Large could shape this as a workable suggestion, it could formally go to the Registry Stakeholders.
Sivasubramanian M x[DELETED ATTACHMENT Screenshot_20180719-152932~2.png, PNG image] _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- -Barry Shein
Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Alejandro Pisanty Facultad de Química UNAM Av. Universidad 3000, 04510 Mexico DF Mexico +52-1-5541444475 FROM ABROAD +525541444475 DESDE MÉXICO SMS +525541444475 Blog: http://pisanty.blogspot.com LinkedIn: http://www.linkedin.com/in/pisanty Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/22285/4A106C0C8614 Twitter: http://twitter.com/apisanty ---->> Unete a ISOC Mexico, http://www.isoc.org . . . . . . . . . . . . . . . .
On Sat, Jul 21, 2018, 12:19 AM Alejandro Pisanty <apisanty@gmail.com> wrote:
Barry,
spot on, plus the idea of a list of forbidden strings appears to be pure lunacy in this context.
All strings are potentially an attack for any substitution of any character
by any IDN look-alike character. The list would contain a couple zillion names and as you say, many could be legtimate. To complicate things further, an ASCII "A" could be used in an homograph attack by substituting for a Greek or Cyrillic "A" as well.
I may be missing something and would study a correction though.
for the Registries, at least in the ASCII space, to volunteer to feed their respective list of harmful names You missed 'at least in ASCII space'.
Alejandro Pisanty
On Fri, Jul 20, 2018 at 1:37 PM, <bzs@theworld.com> wrote:
On July 19, 2018 at 15:48 6.Internet@gmail.com (Sivasubramanian M) wrote:
Please take a look at the attached screenshot of a domainer's offer to sell single character IDNs, for instance an IDN variant (lookalike) of the ASCII character X, which sets a harmful trend. This is an issue if confusability.
The general term for this is "homograph attack" or specifically "IDN homograph attack", where "attack" may be in the eye of the beholder:
https://en.wikipedia.org/wiki/IDN_homograph_attack
and has been the subject of much discussion over recent years and little resolution.
I believe one popular proposal is browser support which either visually flags such IDNs or displays the punycode alongside which is an ASCII represenation and should make obvious that this not what one might suspect.
For example (from this wikipedia page): xn--bcher-kva.tld indicating an umlauted 'u' is in there but importantly that it's not just bucher.tld.
https://en.wikipedia.org/wiki/Punycode
There's still the problem with intent. Could I legitimately offer for sale the strings with and without the umlaut? I think that's generally considered acceptable.
Caveat emptor?
I understand that the Registries (are required to?) maintain a list of
harmful
names for their TLDs, but there is no common minimal list of harmful names. One possible way to achieve this is for the Registries, at least in the ASCII space, to volunteer to feed their respective list of harmful names into a common Registry Stakeholder database, and then draw up a common minimum list of harmful domain names that any Registry could avoid registering.
If At-Large could shape this as a workable suggestion, it could formally go to the Registry Stakeholders.
Sivasubramanian M x[DELETED ATTACHMENT Screenshot_20180719-152932~2.png, PNG image] _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- -Barry Shein
Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Alejandro Pisanty Facultad de Química UNAM Av. Universidad 3000, 04510 Mexico DF Mexico +52-1-5541444475 FROM ABROAD +525541444475 DESDE MÉXICO SMS +525541444475 Blog: http://pisanty.blogspot.com LinkedIn: http://www.linkedin.com/in/pisanty Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/22285/4A106C0C8614 Twitter: http://twitter.com/apisanty ---->> Unete a ISOC Mexico, http://www.isoc.org . . . . . . . . . . . . . . . . _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
Hi, "at least in ASCII space" still can't work. Innumerable strings contain characters that, in turn, have look-alikes in other character sets, many in more than one. To get a sense of scale, try "aardvark" first; EVERY character has a potential substitute. Also please remember the row around ".bg" in Cyrillic. (Again, barring correction from someone more knowledgeable.) Alejandro Pisanty On Fri, Jul 20, 2018 at 1:55 PM, Sivasubramanian M <6.Internet@gmail.com> wrote:
On Sat, Jul 21, 2018, 12:19 AM Alejandro Pisanty <apisanty@gmail.com> wrote:
Barry,
spot on, plus the idea of a list of forbidden strings appears to be pure lunacy in this context.
All strings are potentially an attack for any substitution of any
character by any IDN look-alike character. The list would contain a couple zillion names and as you say, many could be legtimate. To complicate things further, an ASCII "A" could be used in an homograph attack by substituting for a Greek or Cyrillic "A" as well.
I may be missing something and would study a correction though.
for the Registries, at least in the ASCII space, to volunteer to feed their respective list of harmful names
You missed 'at least in ASCII space'.
Alejandro Pisanty
On Fri, Jul 20, 2018 at 1:37 PM, <bzs@theworld.com> wrote:
On July 19, 2018 at 15:48 6.Internet@gmail.com (Sivasubramanian M) wrote:
Please take a look at the attached screenshot of a domainer's offer to sell single character IDNs, for instance an IDN variant (lookalike) of the ASCII character X, which sets a harmful trend. This is an issue if confusability.
The general term for this is "homograph attack" or specifically "IDN homograph attack", where "attack" may be in the eye of the beholder:
https://en.wikipedia.org/wiki/IDN_homograph_attack
and has been the subject of much discussion over recent years and little resolution.
I believe one popular proposal is browser support which either visually flags such IDNs or displays the punycode alongside which is an ASCII represenation and should make obvious that this not what one might suspect.
For example (from this wikipedia page): xn--bcher-kva.tld indicating an umlauted 'u' is in there but importantly that it's not just bucher.tld.
https://en.wikipedia.org/wiki/Punycode
There's still the problem with intent. Could I legitimately offer for sale the strings with and without the umlaut? I think that's generally considered acceptable.
Caveat emptor?
I understand that the Registries (are required to?) maintain a list
of harmful
names for their TLDs, but there is no common minimal list of harmful names. One possible way to achieve this is for the Registries, at least in the ASCII space, to volunteer to feed their respective list of harmful names into a common Registry Stakeholder database, and then draw up a common minimum list of harmful domain names that any Registry could avoid registering.
If At-Large could shape this as a workable suggestion, it could formally go to the Registry Stakeholders.
Sivasubramanian M x[DELETED ATTACHMENT Screenshot_20180719-152932~2.png, PNG image] _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- -Barry Shein
Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Alejandro Pisanty Facultad de Química UNAM <https://maps.google.com/?q=UNAM+Av.+Universidad+3000&entry=gmail&source=g> Av. Universidad 3000 <https://maps.google.com/?q=UNAM+Av.+Universidad+3000&entry=gmail&source=g>, 04510 Mexico DF Mexico +52-1-5541444475 FROM ABROAD +525541444475 DESDE MÉXICO SMS +525541444475 Blog: http://pisanty.blogspot.com LinkedIn: http://www.linkedin.com/in/pisanty Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/ 22285/4A106C0C8614 Twitter: http://twitter.com/apisanty ---->> Unete a ISOC Mexico, http://www.isoc.org . . . . . . . . . . . . . . . . _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Alejandro Pisanty Facultad de Química UNAM Av. Universidad 3000, 04510 Mexico DF Mexico +52-1-5541444475 FROM ABROAD +525541444475 DESDE MÉXICO SMS +525541444475 Blog: http://pisanty.blogspot.com LinkedIn: http://www.linkedin.com/in/pisanty Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/22285/4A106C0C8614 Twitter: http://twitter.com/apisanty ---->> Unete a ISOC Mexico, http://www.isoc.org . . . . . . . . . . . . . . . .
On Sat, Jul 21, 2018, 1:05 AM Alejandro Pisanty <apisanty@gmail.com> wrote:
Hi,
"at least in ASCII space"
at least in plain english still can't work. Innumerable strings contain characters that, in turn,
have look-alikes in other character sets, many in more than one. To get a sense of scale, try "aardvark" first; EVERY character has a potential substitute. Also please remember the row around ".bg" in Cyrillic. (Again, barring correction from someone more knowledgeable.)
Alejandro Pisanty
On Fri, Jul 20, 2018 at 1:55 PM, Sivasubramanian M <6.Internet@gmail.com> wrote:
On Sat, Jul 21, 2018, 12:19 AM Alejandro Pisanty <apisanty@gmail.com> wrote:
Barry,
spot on, plus the idea of a list of forbidden strings appears to be pure lunacy in this context.
All strings are potentially an attack for any substitution of any
character by any IDN look-alike character. The list would contain a couple zillion names and as you say, many could be legtimate. To complicate things further, an ASCII "A" could be used in an homograph attack by substituting for a Greek or Cyrillic "A" as well.
I may be missing something and would study a correction though.
for the Registries, at least in the ASCII space, to volunteer to feed their respective list of harmful names
You missed 'at least in ASCII space'.
Alejandro Pisanty
On Fri, Jul 20, 2018 at 1:37 PM, <bzs@theworld.com> wrote:
On July 19, 2018 at 15:48 6.Internet@gmail.com (Sivasubramanian M) wrote:
Please take a look at the attached screenshot of a domainer's offer to sell single character IDNs, for instance an IDN variant (lookalike) of the ASCII character X, which sets a harmful trend. This is an issue if confusability.
The general term for this is "homograph attack" or specifically "IDN homograph attack", where "attack" may be in the eye of the beholder:
https://en.wikipedia.org/wiki/IDN_homograph_attack
and has been the subject of much discussion over recent years and little resolution.
I believe one popular proposal is browser support which either visually flags such IDNs or displays the punycode alongside which is an ASCII represenation and should make obvious that this not what one might suspect.
For example (from this wikipedia page): xn--bcher-kva.tld indicating an umlauted 'u' is in there but importantly that it's not just bucher.tld.
https://en.wikipedia.org/wiki/Punycode
There's still the problem with intent. Could I legitimately offer for sale the strings with and without the umlaut? I think that's generally considered acceptable.
Caveat emptor?
I understand that the Registries (are required to?) maintain a list
of harmful
names for their TLDs, but there is no common minimal list of harmful names. One possible way to achieve this is for the Registries, at least in the ASCII space, to volunteer to feed their respective list of harmful names into a common Registry Stakeholder database, and then draw up a common minimum list of harmful domain names that any Registry could avoid registering.
If At-Large could shape this as a workable suggestion, it could formally go to the Registry Stakeholders.
Sivasubramanian M x[DELETED ATTACHMENT Screenshot_20180719-152932~2.png, PNG image] _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- -Barry Shein
Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Alejandro Pisanty Facultad de Química UNAM <https://maps.google.com/?q=UNAM+Av.+Universidad+3000&entry=gmail&source=g> Av. Universidad 3000 <https://maps.google.com/?q=UNAM+Av.+Universidad+3000&entry=gmail&source=g>, 04510 Mexico DF Mexico +52-1-5541444475 FROM ABROAD +525541444475 DESDE MÉXICO SMS +525541444475 Blog: http://pisanty.blogspot.com LinkedIn: http://www.linkedin.com/in/pisanty Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/22285/4A106C0C8614 Twitter: http://twitter.com/apisanty ---->> Unete a ISOC Mexico, http://www.isoc.org . . . . . . . . . . . . . . . . _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Alejandro Pisanty Facultad de Química UNAM Av. Universidad 3000, 04510 Mexico DF Mexico +52-1-5541444475 FROM ABROAD +525541444475 DESDE MÉXICO SMS +525541444475 Blog: http://pisanty.blogspot.com LinkedIn: http://www.linkedin.com/in/pisanty Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/22285/4A106C0C8614 Twitter: http://twitter.com/apisanty ---->> Unete a ISOC Mexico, http://www.isoc.org . . . . . . . . . . . . . . . . _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
There is an irrremediable lack of understanding here. Alejandro Pisanty On Fri, Jul 20, 2018 at 3:05 PM, Sivasubramanian M <6.Internet@gmail.com> wrote:
On Sat, Jul 21, 2018, 1:05 AM Alejandro Pisanty <apisanty@gmail.com> wrote:
Hi,
"at least in ASCII space"
at least in plain english
still can't work. Innumerable strings contain characters that, in turn,
have look-alikes in other character sets, many in more than one. To get a sense of scale, try "aardvark" first; EVERY character has a potential substitute. Also please remember the row around ".bg" in Cyrillic. (Again, barring correction from someone more knowledgeable.)
Alejandro Pisanty
On Fri, Jul 20, 2018 at 1:55 PM, Sivasubramanian M <6.Internet@gmail.com> wrote:
On Sat, Jul 21, 2018, 12:19 AM Alejandro Pisanty <apisanty@gmail.com> wrote:
Barry,
spot on, plus the idea of a list of forbidden strings appears to be pure lunacy in this context.
All strings are potentially an attack for any substitution of any
character by any IDN look-alike character. The list would contain a couple zillion names and as you say, many could be legtimate. To complicate things further, an ASCII "A" could be used in an homograph attack by substituting for a Greek or Cyrillic "A" as well.
I may be missing something and would study a correction though.
for the Registries, at least in the ASCII space, to volunteer to feed their respective list of harmful names
You missed 'at least in ASCII space'.
Alejandro Pisanty
On Fri, Jul 20, 2018 at 1:37 PM, <bzs@theworld.com> wrote:
On July 19, 2018 at 15:48 6.Internet@gmail.com (Sivasubramanian M) wrote:
Please take a look at the attached screenshot of a domainer's offer to sell single character IDNs, for instance an IDN variant (lookalike) of the ASCII character X, which sets a harmful trend. This is an issue if confusability.
The general term for this is "homograph attack" or specifically "IDN homograph attack", where "attack" may be in the eye of the beholder:
https://en.wikipedia.org/wiki/IDN_homograph_attack
and has been the subject of much discussion over recent years and little resolution.
I believe one popular proposal is browser support which either visually flags such IDNs or displays the punycode alongside which is an ASCII represenation and should make obvious that this not what one might suspect.
For example (from this wikipedia page): xn--bcher-kva.tld indicating an umlauted 'u' is in there but importantly that it's not just bucher.tld.
https://en.wikipedia.org/wiki/Punycode
There's still the problem with intent. Could I legitimately offer for sale the strings with and without the umlaut? I think that's generally considered acceptable.
Caveat emptor?
I understand that the Registries (are required to?) maintain a list
of harmful
names for their TLDs, but there is no common minimal list of harmful names. One possible way to achieve this is for the Registries, at least in the ASCII space, to volunteer to feed their respective list of harmful names into a common Registry Stakeholder database, and then draw up a common minimum list of harmful domain names that any Registry could avoid registering.
If At-Large could shape this as a workable suggestion, it could formally go to the Registry Stakeholders.
Sivasubramanian M x[DELETED ATTACHMENT Screenshot_20180719-152932~2.png, PNG image] _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- -Barry Shein
Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Alejandro Pisanty Facultad de Química UNAM <https://maps.google.com/?q=UNAM+Av.+Universidad+3000&entry=gmail&source=g> Av. Universidad 3000 <https://maps.google.com/?q=UNAM+Av.+Universidad+3000&entry=gmail&source=g>, 04510 Mexico DF Mexico +52-1-5541444475 FROM ABROAD +525541444475 DESDE MÉXICO SMS +525541444475 Blog: http://pisanty.blogspot.com LinkedIn: http://www.linkedin.com/in/pisanty Unete al grupo UNAM <https://maps.google.com/?q=UNAM+Av.+Universidad+3000&entry=gmail&source=g> en LinkedIn, http://www.linkedin.com/e/gis/22285/4A106C0C8614 Twitter: http://twitter.com/apisanty ---->> Unete a ISOC Mexico, http://www.isoc.org . . . . . . . . . . . . . . . . _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Alejandro Pisanty Facultad de Química UNAM Av. Universidad 3000 <https://maps.google.com/?q=UNAM+Av.+Universidad+3000&entry=gmail&source=g>, 04510 Mexico DF Mexico +52-1-5541444475 FROM ABROAD +525541444475 DESDE MÉXICO SMS +525541444475 Blog: http://pisanty.blogspot.com LinkedIn: http://www.linkedin.com/in/pisanty Unete al grupo UNAM <https://maps.google.com/?q=UNAM+Av.+Universidad+3000&entry=gmail&source=g> en LinkedIn, http://www.linkedin.com/e/gis/22285/4A106C0C8614 Twitter: http://twitter.com/apisanty ---->> Unete a ISOC Mexico, http://www.isoc.org . . . . . . . . . . . . . . . . _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Alejandro Pisanty Facultad de Química UNAM Av. Universidad 3000, 04510 Mexico DF Mexico +52-1-5541444475 FROM ABROAD +525541444475 DESDE MÉXICO SMS +525541444475 Blog: http://pisanty.blogspot.com LinkedIn: http://www.linkedin.com/in/pisanty Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/22285/4A106C0C8614 Twitter: http://twitter.com/apisanty ---->> Unete a ISOC Mexico, http://www.isoc.org . . . . . . . . . . . . . . . .
Mixing scripts on the left and right is a sin initially. Cool registries ban it at EPP level. --andrei 2018-07-20 22:34 GMT+03:00 Alejandro Pisanty <apisanty@gmail.com>:
Hi,
"at least in ASCII space" still can't work. Innumerable strings contain characters that, in turn, have look-alikes in other character sets, many in more than one. To get a sense of scale, try "aardvark" first; EVERY character has a potential substitute. Also please remember the row around ".bg" in Cyrillic. (Again, barring correction from someone more knowledgeable.)
Alejandro Pisanty
On Fri, Jul 20, 2018 at 1:55 PM, Sivasubramanian M <6.Internet@gmail.com> wrote:
On Sat, Jul 21, 2018, 12:19 AM Alejandro Pisanty <apisanty@gmail.com> wrote:
Barry,
spot on, plus the idea of a list of forbidden strings appears to be pure lunacy in this context.
All strings are potentially an attack for any substitution of any
character by any IDN look-alike character. The list would contain a couple zillion names and as you say, many could be legtimate. To complicate things further, an ASCII "A" could be used in an homograph attack by substituting for a Greek or Cyrillic "A" as well.
I may be missing something and would study a correction though.
for the Registries, at least in the ASCII space, to volunteer to feed their respective list of harmful names
You missed 'at least in ASCII space'.
Alejandro Pisanty
On Fri, Jul 20, 2018 at 1:37 PM, <bzs@theworld.com> wrote:
On July 19, 2018 at 15:48 6.Internet@gmail.com (Sivasubramanian M) wrote:
Please take a look at the attached screenshot of a domainer's offer to sell single character IDNs, for instance an IDN variant (lookalike) of the ASCII character X, which sets a harmful trend. This is an issue if confusability.
The general term for this is "homograph attack" or specifically "IDN homograph attack", where "attack" may be in the eye of the beholder:
https://en.wikipedia.org/wiki/IDN_homograph_attack
and has been the subject of much discussion over recent years and little resolution.
I believe one popular proposal is browser support which either visually flags such IDNs or displays the punycode alongside which is an ASCII represenation and should make obvious that this not what one might suspect.
For example (from this wikipedia page): xn--bcher-kva.tld indicating an umlauted 'u' is in there but importantly that it's not just bucher.tld.
https://en.wikipedia.org/wiki/Punycode
There's still the problem with intent. Could I legitimately offer for sale the strings with and without the umlaut? I think that's generally considered acceptable.
Caveat emptor?
I understand that the Registries (are required to?) maintain a list
of harmful
names for their TLDs, but there is no common minimal list of harmful names. One possible way to achieve this is for the Registries, at least in the ASCII space, to volunteer to feed their respective list of harmful names into a common Registry Stakeholder database, and then draw up a common minimum list of harmful domain names that any Registry could avoid registering.
If At-Large could shape this as a workable suggestion, it could formally go to the Registry Stakeholders.
Sivasubramanian M x[DELETED ATTACHMENT Screenshot_20180719-152932~2.png, PNG image] _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- -Barry Shein
Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Alejandro Pisanty Facultad de Química UNAM <https://maps.google.com/?q=UNAM+Av.+Universidad+3000&entry=gmail&source=g> Av. Universidad 3000 <https://maps.google.com/?q=UNAM+Av.+Universidad+3000&entry=gmail&source=g>, 04510 Mexico DF Mexico +52-1-5541444475 FROM ABROAD +525541444475 DESDE MÉXICO SMS +525541444475 Blog: http://pisanty.blogspot.com LinkedIn: http://www.linkedin.com/in/pisanty Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/ 22285/4A106C0C8614 Twitter: http://twitter.com/apisanty ---->> Unete a ISOC Mexico, http://www.isoc.org . . . . . . . . . . . . . . . . _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Alejandro Pisanty Facultad de Química UNAM Av. Universidad 3000, 04510 Mexico DF Mexico +52-1-5541444475 FROM ABROAD +525541444475 DESDE MÉXICO SMS +525541444475 Blog: http://pisanty.blogspot.com LinkedIn: http://www.linkedin.com/in/pisanty Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/ 22285/4A106C0C8614 Twitter: http://twitter.com/apisanty ---->> Unete a ISOC Mexico, http://www.isoc.org . . . . . . . . . . . . . . . .
_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- Andrey Kolesnikov RIPN.NET
Andrei, thanks. Exactly. No list of "forbidden strings" - just one good practice. A lot of mischief can be done in the remaining space but at least that one bad practice can be taken off the table. Alejandro Pisanty - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Alejandro Pisanty Facultad de Química UNAM Av. Universidad 3000, 04510 Mexico DF Mexico +52-1-5541444475 FROM ABROAD +525541444475 DESDE MÉXICO SMS +525541444475 Blog: http://pisanty.blogspot.com LinkedIn: http://www.linkedin.com/in/pisanty Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/22285/4A106C0C8614 Twitter: http://twitter.com/apisanty ---->> Unete a ISOC Mexico, http://www.isoc.org . . . . . . . . . . . . . . . . ________________________________ Desde: At-Large [at-large-bounces@atlarge-lists.icann.org] en nombre de Andrei Kolesnikov [andrei@rol.ru] Enviado el: lunes, 23 de julio de 2018 11:05 Hasta: Alejandro Pisanty CC: At-Large Staff; At-Large Worldwide Asunto: Re: [At-Large] IDN Variants in the market place Mixing scripts on the left and right is a sin initially. Cool registries ban it at EPP level. --andrei 2018-07-20 22:34 GMT+03:00 Alejandro Pisanty <apisanty@gmail.com<mailto:apisanty@gmail.com>>: Hi, "at least in ASCII space" still can't work. Innumerable strings contain characters that, in turn, have look-alikes in other character sets, many in more than one. To get a sense of scale, try "aardvark" first; EVERY character has a potential substitute. Also please remember the row around ".bg" in Cyrillic. (Again, barring correction from someone more knowledgeable.) Alejandro Pisanty On Fri, Jul 20, 2018 at 1:55 PM, Sivasubramanian M <6.Internet@gmail.com<mailto:6.Internet@gmail.com>> wrote: On Sat, Jul 21, 2018, 12:19 AM Alejandro Pisanty <apisanty@gmail.com<mailto:apisanty@gmail.com>> wrote: Barry, spot on, plus the idea of a list of forbidden strings appears to be pure lunacy in this context. All strings are potentially an attack for any substitution of any character by any IDN look-alike character. The list would contain a couple zillion names and as you say, many could be legtimate. To complicate things further, an ASCII "A" could be used in an homograph attack by substituting for a Greek or Cyrillic "A" as well. I may be missing something and would study a correction though. for the Registries, at least in the ASCII space, to volunteer to feed their respective list of harmful names You missed 'at least in ASCII space'. Alejandro Pisanty On Fri, Jul 20, 2018 at 1:37 PM, <bzs@theworld.com<mailto:bzs@theworld.com>> wrote: On July 19, 2018 at 15:48 6.Internet@gmail.com<mailto:6.Internet@gmail.com> (Sivasubramanian M) wrote:
Please take a look at the attached screenshot of a domainer's offer to sell single character IDNs, for instance an IDN variant (lookalike) of the ASCII character X, which sets a harmful trend. This is an issue if confusability.
The general term for this is "homograph attack" or specifically "IDN homograph attack", where "attack" may be in the eye of the beholder: https://en.wikipedia.org/wiki/IDN_homograph_attack and has been the subject of much discussion over recent years and little resolution. I believe one popular proposal is browser support which either visually flags such IDNs or displays the punycode alongside which is an ASCII represenation and should make obvious that this not what one might suspect. For example (from this wikipedia page): xn--bcher-kva.tld indicating an umlauted 'u' is in there but importantly that it's not just bucher.tld. https://en.wikipedia.org/wiki/Punycode There's still the problem with intent. Could I legitimately offer for sale the strings with and without the umlaut? I think that's generally considered acceptable. Caveat emptor?
I understand that the Registries (are required to?) maintain a list of harmful names for their TLDs, but there is no common minimal list of harmful names. One possible way to achieve this is for the Registries, at least in the ASCII space, to volunteer to feed their respective list of harmful names into a common Registry Stakeholder database, and then draw up a common minimum list of harmful domain names that any Registry could avoid registering.
If At-Large could shape this as a workable suggestion, it could formally go to the Registry Stakeholders.
Sivasubramanian M x[DELETED ATTACHMENT Screenshot_20180719-152932~2.png, PNG image] _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org<mailto:At-Large@atlarge-lists.icann.org> https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org<mailto:At-Large@atlarge-lists.icann.org> https://atlarge-lists.icann.org/mailman/listinfo/at-large At-Large Official Site: http://atlarge.icann.org -- - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Alejandro Pisanty Facultad de Química UNAM<https://maps.google.com/?q=UNAM+Av.+Universidad+3000&entry=gmail&source=g> Av. Universidad 3000<https://maps.google.com/?q=UNAM+Av.+Universidad+3000&entry=gmail&source=g>, 04510 Mexico DF Mexico +52-1-5541444475 FROM ABROAD +525541444475 DESDE MÉXICO SMS +525541444475 Blog: http://pisanty.blogspot.com LinkedIn: http://www.linkedin.com/in/pisanty Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/22285/4A106C0C8614 Twitter: http://twitter.com/apisanty ---->> Unete a ISOC Mexico, http://www.isoc.org . . . . . . . . . . . . . . . . _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org<mailto:At-Large@atlarge-lists.icann.org> https://atlarge-lists.icann.org/mailman/listinfo/at-large At-Large Official Site: http://atlarge.icann.org -- - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Alejandro Pisanty Facultad de Química UNAM Av. Universidad 3000, 04510 Mexico DF Mexico +52-1-5541444475 FROM ABROAD +525541444475 DESDE MÉXICO SMS +525541444475 Blog: http://pisanty.blogspot.com LinkedIn: http://www.linkedin.com/in/pisanty Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/22285/4A106C0C8614 Twitter: http://twitter.com/apisanty ---->> Unete a ISOC Mexico, http://www.isoc.org . . . . . . . . . . . . . . . . _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org<mailto:At-Large@atlarge-lists.icann.org> https://atlarge-lists.icann.org/mailman/listinfo/at-large At-Large Official Site: http://atlarge.icann.org -- Andrey Kolesnikov RIPN.NET<http://RIPN.NET>
The full character permutation set is daunting. How about simplified versus traditional Chinese? Or Chinese vs Japanese? Who knows what potential mischief lurks in the world's character sets? Which leads to the closely related problem of domains which contain semantically equivalent but visually different characters. In ASCII and Latin-1 we have upper/lower case so just naturally treat example.com and EXAMPLE.COM identically in the DNS. How does that concept extend to other character sets? I believe there are collisions between Arabic and Farsi, for example, or I once sat in on someone who seemed knowledgeable talking about this and how it affects domain uniqueness. Dennis Jennings worked on this, there were committees and coffee! -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
On Sat, Jul 21, 2018 at 12:08 AM <bzs@theworld.com> wrote:
On July 19, 2018 at 15:48 6.Internet@gmail.com (Sivasubramanian M) wrote:
Please take a look at the attached screenshot of a domainer's offer to sell single character IDNs, for instance an IDN variant (lookalike) of the ASCII character X, which sets a harmful trend. This is an issue if confusability.
The general term for this is "homograph attack" or specifically "IDN homograph attack", where "attack" may be in the eye of the beholder:
https://en.wikipedia.org/wiki/IDN_homograph_attack
and has been the subject of much discussion over recent years and little resolution.
I believe one popular proposal is browser support which either visually flags such IDNs or displays the punycode alongside which is an ASCII represenation and should make obvious that this not what one might suspect.
For example (from this wikipedia page): xn--bcher-kva.tld indicating an umlauted 'u' is in there but importantly that it's not just bucher.tld.
https://en.wikipedia.org/wiki/Punycode
There's still the problem with intent. Could I legitimately offer for sale the strings with and without the umlaut? I think that's generally considered acceptable.
Caveat emptor?
Caveat emptor doesn't work. 6.999 out of 7 billion have no clue whatsoever about Variants.
I understand that the Registries (are required to?) maintain a list of
harmful
names for their TLDs, but there is no common minimal list of harmful names. One possible way to achieve this is for the Registries, at least in the ASCII space, to volunteer to feed their respective list of harmful names into a common Registry Stakeholder database, and then draw up a common minimum list of harmful domain names that any Registry could avoid registering.
If At-Large could shape this as a workable suggestion, it could formally go to the Registry Stakeholders.
Sivasubramanian M x[DELETED ATTACHMENT Screenshot_20180719-152932~2.png, PNG image] _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
-- -Barry Shein
Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
This homograph problem is not new and has been been worked on for well over a decade. Type "homograph attack" into your favorite search engine. But briefly: 1. You can type x.com and DNS (and other layers) can indeed redirect you to the cyrillic x.com or anywhere they like. The primary defense you have against this are security layers such as SSL (https) which can, to some cryptographic certainty, verify who you finally connected to. Of course they are perfectly capable of responding, with great confidence, that you indeed have arrived at a site owned by some bad actor. SSL certificates are cheap and even the most expensive only certify that you are indeed "Mr Bad Actor" and perhaps have managed to obtain some corporate credentials such as a DUN number. Not a very exclusive club. And you'd have to be motivated to check that it's who you intended to connect to, none of this can read your mind. Maybe you do business with Mr Bad Actor, someone must. 2. When I said "attack" is in the eye of the beholder I was quite serious. For example why SHOULDN'T cyrillic X.com exist? Because you or some subset of the internet find it potentially confusing? We abandoned the notion that the internet is ASCII-only or even ISO/IEC 8859-1 only (aka Latin-1, includes Western European characters such as umlauted-u) many years ago. https://en.wikipedia.org/wiki/ISO/IEC_8859-1 One can assert "but I (or some other billions) must never be confused!" but as they say if wishes were horses...or perhaps put better this genie isn't likely going back in the bottle. The other choice is to somehow enforce against malicious uses rather than potentially malicious uses which is another huge topic covering everything from "define malicious!" to "how, exactly, would you enforce this?" 3. A lot of this reduces to what's often called "reputational services": How do I verify (preferably with little effort) the reputation of some resource I am accessing? Gratuitous anecdote: In 2003 I was one of two keynote speakers at the MIT Spam Conference. The other speaker's talk was about DKIM, a crpytographically based way to verify that an email has come from the signing party. I rudely (perhaps) asked at the end how do I know I have only verified they are indeed Mr Bad Actor? And the speaker said: Reputational services! They are being developed and will augment this protocol to solve exactly that problem. 2003. Do you see any reputational services? I don't. Or not beyond some singular efforts where a search engine tries to flag a link as potentially malicious. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
Dear Barry, On 21/07/2018 04:47, bzs@theworld.com wrote:
And the speaker said: Reputational services! They are being developed and will augment this protocol to solve exactly that problem.
2003.
Do you see any reputational services? I don't.
Or not beyond some singular efforts where a search engine tries to flag a link as potentially malicious.
There is a lot of added software coming from the likes of Symantec & others that perform reputational services, only you don't see it because all the spam that they filter out is essentially not seen by the end user. Same for all of the blacklists like SpamCop etc. That's DNS reputational services for you. You can go as far as actually not really knowing what these people do and sub-contracting your email handling to the Microsoft Cloud or Google/Gmail, or other hosted spam filtering services. BTW am I the only person who is still amazed at how many companies including banks neither use DKIM nor TLS for their emails? Kindest regards, Olivier
On Mon, Jul 23, 2018, 6:11 PM Olivier MJ Crépin-Leblond <ocl@gih.com> wrote:
Dear Barry,
On 21/07/2018 04:47, bzs@theworld.com wrote:
And the speaker said: Reputational services! They are being developed and will augment this protocol to solve exactly that problem.
2003.
Do you see any reputational services? I don't.
Or not beyond some singular efforts where a search engine tries to flag a link as potentially malicious.
There is a lot of added software coming from the likes of Symantec & others that perform reputational services, only you don't see it because all the spam that they filter out is essentially not seen by the end user. Same for all of the blacklists like SpamCop etc.
Symantec services are of benefit to Symantec users and not All Users. At least do these different businesses exchange information between one another and collaborate? That's DNS reputational services for you.
Internet requires a Reputation Service that is free from commercial agenda and free from political bias. You can go as far as actually not really knowing what these people do
Not knowing what they do is not OK. A good reputation service needs to a system of ranking that is fair, actually more responsive to domain names or Internet resources that require false positives reversed. In the current environment, it requires expert help even to know that there is a false reputation record somewhere, and is almost a dead wall when you try to get to them to reverse it. and sub-contracting your email handling to the Microsoft Cloud or
Google/Gmail, or other hosted spam filtering services.
BTW am I the only person who is still amazed at how many companies including banks neither use DKIM nor TLS for their emails?
Kindest regards,
Olivier
On 7/23/18 5:57 AM, sivasubramanian muthusamy wrote:
Internet requires a Reputation Service that is free from commercial agenda and free from political bias. The usual internet answer to that is "go forth and build it".
I do not mean that in any way that is sarcastic or pejorative. I really mean, if you want this, then the internet is open for you to build it. That, of course, means building it to your own design, through your own effort and expense, and without any promise that other users would actually use it or perceive it as free of bias. --karl--
On July 23, 2018 at 13:41 ocl@gih.com (Olivier MJ Crépin-Leblond) wrote:
Dear Barry,
On 21/07/2018 04:47, bzs@theworld.com wrote:
And the speaker said: Reputational services! They are being developed and will augment this protocol to solve exactly that problem.
2003.
Do you see any reputational services? I don't.
Or not beyond some singular efforts where a search engine tries to flag a link as potentially malicious.
There is a lot of added software coming from the likes of Symantec & others that perform reputational services, only you don't see it because all the spam that they filter out is essentially not seen by the end user. Same for all of the blacklists like SpamCop etc. That's DNS reputational services for you. You can go as far as actually not really knowing what these people do and sub-contracting your email handling to the Microsoft Cloud or Google/Gmail, or other hosted spam filtering services.
That's a good point though it has evolved to be more of a binary choice, good or bad.
From his remarks I was expecting something more like a credit score.
Spamassassin tries to divine that via various methods, including optionally such lists, but by default just features of the email itself such as does it contain "invisible" text (white text on white background) probably intended to deceive Bayes filters or similar,
From this it develops a scoring and one can accept/reject/flag based on that score.
BTW am I the only person who is still amazed at how many companies including banks neither use DKIM nor TLS for their emails?
Amazed? Maybe I'm more cynical. Many probably view this as potentially rendering their precious email pitches undeliverable to many. Barely on topic but I will continue my prediction that "Spam-II The Next Generation" will involve sources you have had some legitimate contact with but now you're being inundated from them and hundreds like them. For example I just got a legitimate email from my landline provider (yeah yeah) that I Must Pay My Bill Today Or Else! Some inspection revealed it's not due for about 3 weeks...but hey, why not?, email is just about free, dialing for dollars!, prey on the easily frightened. I'm just thankful they don't send a message like that hourly tho there are some vendors I've bought from who do send some sort of pitch nearly hourly, certainly several times per day, every day. Yes they're more easily automatically filtered than bad actors but is one really going to filter out their utility companies? Or how much work should one do to separate their wheat from their chaff? -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
There is a widespread misconception about DNS that it is somehow an authoritative service, by which I mean that if one says "connect to X.Y.Z that one is, in fact, going to be connected to X.Y.Z." That misconception is partially fueled by the "authoritative answer" bit in the DNS reply packet. That bit merely means that the DNS server that generated the answer got the information from its own configuration files rather than overhearing it via the kind of DNS hearsay activity that occurs within DNS order to make DNS more efficient. What you might notice is that the internet architecture is missing a layer. Way back in the mid 1970's we tried to insert a layer above TCP and UDP in which there would be an exchange of mutual identification and credentials proving that identification. Due to security (or rather paranoia) concerns of certain US government agencies, that layer never made it into the internet architecture. And, because such a layer tends to imply a universal authority over the issuance of those credentials, there was pushback by those who favored a more diffuse internet with less centralization. Had that layer been present, then when one tries to connect to "X.com" after that connection had been established at the TCP level there would have been an exchange that would prove whether the connection had reached the desired "X.com" or a homographic (typically with intent to deceive) different target. DNS is intended to be a "hinting" system, by which I mean that it gives information that it (and you) hope is accurate but about which there are really no guarantees, leaving security as a job for the user to perform. We see that job being added in later years via TLS certificate chains (which are often merely tracked back to a known certificate authority, which is an inadequate test, but it is the test most often done.) DNSSEC also provides tools so that one can know that the DNS data has not been modified somewhere, but that does not change the nature of the address information in DNS resource records being merely a hint. DNS, because of caching, can never become give ironclad promises that the result you get from your local DNS resolver is utterly accurate. And with the rise of geo-IP based DNS mappings, the definition of "accurate" becomes somewhat contextual. The real answer to homographic deceptions is not really within the realm of DNS itself, or within ICANN but, rather, would be through the adoption (at long last) of a proper layer of mutual identification and authentication either within the transport protocols or between them and the applications. None of this is easy - just look at how SSL evolved, and grew, to become TLS 1.1, 1.2, 1.3 ... And nobody has ever said that DNSSEC is simple. --karl--
On Sat, Jul 21, 2018 at 2:00 AM Karl Auerbach <karl@cavebear.com> wrote:
There is a widespread misconception about DNS that it is somehow an authoritative service, by which I mean that if one says "connect to X.Y.Z that one is, in fact, going to be connected to X.Y.Z."
That misconception is partially fueled by the "authoritative answer" bit in the DNS reply packet. That bit merely means that the DNS server that generated the answer got the information from its own configuration files rather than overhearing it via the kind of DNS hearsay activity that occurs within DNS order to make DNS more efficient.
What you might notice is that the internet architecture is missing a layer. Way back in the mid 1970's we tried to insert a layer above TCP and UDP in which there would be an exchange of mutual identification and credentials proving that identification. Due to security (or rather paranoia) concerns of certain US government agencies, that layer never made it into the internet architecture. And, because such a layer tends to imply a universal authority over the issuance of those credentials, there was pushback by those who favored a more diffuse internet with less centralization.
Had that layer been present, then when one tries to connect to "X.com" after that connection had been established at the TCP level there would have been an exchange that would prove whether the connection had reached the desired "X.com" or a homographic (typically with intent to deceive) different target.
Is there a flaw in the argument here? If the user wants the ASCII x.com, and queries by typing x.com by an ASCII keyboard, the DNS server is not likely to misdirect the query to the homographic domain's webspace. If such a likelihood were to exist, a mutual identification layer would minimise the misdirection. What we are concerned here is more of a situation of a user not knowing that there are two x.com domains, and not knowing that there are two different webspaces. The user might have been presented with a link to the homographic x.com which he clicks on, in which case the DNS server would respond by giving the user the answer to the query, which actually happens to be a query for the location of the homographic x.com. How would an identification layer have helped in this case?
DNS is intended to be a "hinting" system, by which I mean that it gives information that it (and you) hope is accurate but about which there are really no guarantees, leaving security as a job for the user to perform.
We see that job being added in later years via TLS certificate chains (which are often merely tracked back to a known certificate authority, which is an inadequate test, but it is the test most often done.) DNSSEC also provides tools so that one can know that the DNS data has not been modified somewhere, but that does not change the nature of the address information in DNS resource records being merely a hint.
DNS, because of caching, can never become give ironclad promises that the result you get from your local DNS resolver is utterly accurate. And with the rise of geo-IP based DNS mappings, the definition of "accurate" becomes somewhat contextual.
The real answer to homographic deceptions is not really within the realm of DNS itself, or within ICANN but, rather, would be through the adoption (at long last) of a proper layer of mutual identification and authentication either within the transport protocols or between them and the applications.
None of this is easy - just look at how SSL evolved, and grew, to become TLS 1.1, 1.2, 1.3 ... And nobody has ever said that DNSSEC is simple.
--karl--
I support this Siva and would call on the ALAC chair and ALAC to direct the At Large Working Group on IDNs to put a paper together for the community to input into to capture, Siva's concerns and those views averse to the notion so we can have a broad macro view of the same. Particularly, the major RALOs that would be affected are EURALO and APRALO and notwithstanding other RALOs at all. Many thanks, Sala On Thu, 19 Jul 2018, 10:19 pm Sivasubramanian M, <6.Internet@gmail.com> wrote:
Please take a look at the attached screenshot of a domainer's offer to sell single character IDNs, for instance an IDN variant (lookalike) of the ASCII character X, which sets a harmful trend. This is an issue if confusability.
I understand that the Registries (are required to?) maintain a list of harmful names for their TLDs, but there is no common minimal list of harmful names. One possible way to achieve this is for the Registries, at least in the ASCII space, to volunteer to feed their respective list of harmful names into a common Registry Stakeholder database, and then draw up a common minimum list of harmful domain names that any Registry could avoid registering.
If At-Large could shape this as a workable suggestion, it could formally go to the Registry Stakeholders.
Sivasubramanian M _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
Thank you Sala. Such a broad macroview by ALAC as you have suggested would lead to solutions through the ICANN processes. Sivasubramanian M On Sat, Jul 21, 2018, 4:05 AM Salanieta T. Tamanikaiwaimaro < salanieta.tamanikaiwaimaro@gmail.com> wrote:
I support this Siva and would call on the ALAC chair and ALAC to direct the At Large Working Group on IDNs to put a paper together for the community to input into to capture, Siva's concerns and those views averse to the notion so we can have a broad macro view of the same.
Particularly, the major RALOs that would be affected are EURALO and APRALO and notwithstanding other RALOs at all.
Many thanks, Sala
On Thu, 19 Jul 2018, 10:19 pm Sivasubramanian M, <6.Internet@gmail.com> wrote:
Please take a look at the attached screenshot of a domainer's offer to sell single character IDNs, for instance an IDN variant (lookalike) of the ASCII character X, which sets a harmful trend. This is an issue if confusability.
I understand that the Registries (are required to?) maintain a list of harmful names for their TLDs, but there is no common minimal list of harmful names. One possible way to achieve this is for the Registries, at least in the ASCII space, to volunteer to feed their respective list of harmful names into a common Registry Stakeholder database, and then draw up a common minimum list of harmful domain names that any Registry could avoid registering.
If At-Large could shape this as a workable suggestion, it could formally go to the Registry Stakeholders.
Sivasubramanian M _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
participants (10)
-
Alejandro Pisanty -
Andrei Kolesnikov -
bzs＠theworld.com -
Dr. Alejandro Pisanty Baruch -
Hadia Abdelsalam Mokhtar EL miniawi -
Karl Auerbach -
Olivier MJ Crépin-Leblond -
Salanieta T. Tamanikaiwaimaro -
Sivasubramanian M -
sivasubramanian muthusamy