Re: Dear RIPE: Please don't encourage phishing
So it's necessary to throw the baby out with the bathwater, and tell them never to click on a link...
That baby was ugly anyway brandon
On 10 February 2012 16:09, Brandon Butterworth <brandon@rd.bbc.co.uk> wrote:
So it's necessary to throw the baby out with the bathwater, and tell them never to click on a link...
That baby was ugly anyway
HAHAHA. My $0.02 on this issue is if the message is rich text I hover over the link and see where it actually sends me. If I don't know what that link is then I don't click it. Not sure how long it's going to take, probably a generation, for people to use some sense before mindlessly clicking on stuff. Banks and businesses that keep sensitive information in a protected area on the web for you should start sending messages in PLAIN TEXT so you have to copy/paste the link if you don't already have it book marked or don't want to type it. Sure it's not all flashy and there's no nice pictures and junk but if you get an email from your bank that's not in plain text and contains hyperlinks then you'll know it's fake before you even read it. --- Landon Stewart <lstewart@superb.net <mailto"LStewart@Superb.Net>> Manager of Systems and Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": www.superb.net
Randy Bush wrote:
My $0.02 on this issue is if the message is rich text I hover over the link and see where it actually sends me.
idn has made this unsafe
I pointed it out at IETF Munich in 1997 that with an example of: MICROSOFT.COM where 'C' of MICROSOFT is actually a Cyrillic character. But, people insisted working on useless IDN. Masataka Ohta
On 11/02/12 01:16, Masataka Ohta wrote:
Randy Bush wrote:
My $0.02 on this issue is if the message is rich text I hover over the link and see where it actually sends me. idn has made this unsafe I pointed it out at IETF Munich in 1997 that with an example of:
MICROSOFT.COM
where 'C' of MICROSOFT is actually a Cyrillic character.
But, people insisted working on useless IDN.
Masataka Ohta
Techniques to deal with this sort of spoofing already exist: see http://www.mozilla.org/projects/security/tld-idn-policy-list.html for one quite effective approach. -- Neil
My $0.02 on this issue is if the message is rich text I hover over the link and see where it actually sends me. idn has made this unsafe Techniques to deal with this sort of spoofing already exist: see http://www.mozilla.org/projects/security/tld-idn-policy-list.html for one quite effective approach.
and grandma is gonna use this? with internet exploder or safari? let's try to remember that there are normal human beings on the net these years (bummer that, eh?), and this list is kind of about serving them. randy
The internet was way cooler before that chris On Feb 11, 2012 12:09 PM, "Randy Bush" <randy@psg.com> wrote:
My $0.02 on this issue is if the message is rich text I hover over the link and see where it actually sends me. idn has made this unsafe Techniques to deal with this sort of spoofing already exist: see http://www.mozilla.org/projects/security/tld-idn-policy-list.html for one quite effective approach.
and grandma is gonna use this? with internet exploder or safari?
let's try to remember that there are normal human beings on the net these years (bummer that, eh?), and this list is kind of about serving them.
randy
On Feb 11, 2012, at 12:13 PM, chris wrote:
The internet was way cooler before that
Yes, and a lot of us could run open relays on our SMTP servers to help each other out, and a full usenet feed fit on a plain ol' 9600 baud link. But no way I could have at home the kind of bandwidth I can get today for a very reasonable price, and so on. -jav
On Sat, 11 Feb 2012 09:09:25 PST, Randy Bush said:
My $0.02 on this issue is if the message is rich text I hover over the link and see where it actually sends me. idn has made this unsafe Techniques to deal with this sort of spoofing already exist: see http://www.mozilla.org/projects/security/tld-idn-policy-list.html for one quite effective approach.
Nice. Basically, unless the TLD registrar has a public policy that basically says "We don't allow names with cyrillic C to collide with MICROSOFT", their hostnames all get displayed as xn--gobbledygook. (The actual policy for the .UA registrar is more subtle. They *do* in fact allow "U+0441 Cyrillic Small Letter ES" which is visually a C to us Latin-glyph users. However, they require at least one character that's visually unique to Cyrillic in the domain name. They also don't allow mixed Cyrillic/Latin scripts in one domain name). Or so http://www.hostmaster.ua/idn/ tells me after Google Translate gets done with it. ;)
and grandma is gonna use this? with internet exploder or safari?
If the manufacturers of IE and Safari can't come up with a similar policy, then the people at Mozilla can use "We protect you from malicious names" as a marketing diffferentiation feature.
Valdis.Kletnieks@vt.edu wrote:
(The actual policy for the .UA registrar is more subtle. They *do* in fact allow "U+0441 Cyrillic Small Letter ES" which is visually a C to us Latin-glyph users. However, they require at least one character that's visually unique to Cyrillic in the domain name.
Unique within what? Is a Cyrillic character, which looks like Latin E with diaeresis, a unique Cyrillic character? Is "CYRILLIC CAPITAL LETTER GHE", which looks like Greek Gamma, a unique Cyrillic character? Is Greek Gamma, which looks like "CYRILLIC CAPITAL LETTER GHE", a unique Greek character?
They also don't allow mixed Cyrillic/Latin scripts in one domain name).
Is a Russian word containing no unique (unique to ASCII) Cyrillic characters encoded as Latin character using ASCII, even though a Russian word containing unique (whatever unique means) Cyrillic character encoded as Cyrillic characters? It is obvious that such confused scheme encourage phishing a lot.
If the manufacturers of IE and Safari can't come up with a similar policy, then the people at Mozilla can use "We protect you from malicious names" as a marketing diffferentiation feature.
The only protection is to disable IDN. Masataka Ohta
On Sun, 12 Feb 2012 10:25:53 +0900, Masataka Ohta said:
Valdis.Kletnieks@vt.edu wrote:
(The actual policy for the .UA registrar is more subtle. They *do* in fact allow "U+0441 Cyrillic Small Letter ES" which is visually a C to us Latin-glyph users. However, they require at least one character that's visually unique to Cyrillic in the domain name.
Unique within what?
Is a Cyrillic character, which looks like Latin E with diaeresis, a unique Cyrillic character?
Is "CYRILLIC CAPITAL LETTER GHE", which looks like Greek Gamma, a unique Cyrillic character?
Is Greek Gamma, which looks like "CYRILLIC CAPITAL LETTER GHE", a unique Greek character?
Doesn't actually matter, because the .ua registry isn't allowing Greek Gamma or Latin-E-with-diaresis, in domain names. So you can't find a domain bankname-containing-ghe.ua and spoof it with bankname-containing-gamma.ua. I suppose you *could* find a 'greek-bankame-containing-gamma-and-only-chars-spoofable-in-cyrillic.gr' and create a 'bankname-containing-ghe-and-cyrillic.ua'. But quite frankly, turning off IDN doesn't fix that problem - greekbank.gr is spoofable by greekbank.ua and greekbank.com. We *already* have companies that will register 'foobar.com', 'foobar.net', 'foobar.org' and every other variant they can to prevent squatters in the other TLDs.
They also don't allow mixed Cyrillic/Latin scripts in one domain name).
Is a Russian word containing no unique (unique to ASCII) Cyrillic characters encoded as Latin character using ASCII, even though a Russian word containing unique (whatever unique means) Cyrillic character encoded as Cyrillic characters?
No, it means you get to pick 'all-latin-chars.ua' or 'all-cyrillic-chars.ua'. And due to the requirement that a cyrillic name have a special char in it, you can's spoof an all-latin-chars.ua name.
The only protection is to disable IDN.
You also have to ban the use of numbers in domain names, because you need to prevent people being tricked by micros0ft.com and m1crosoft.com. Good luck on that. Oh, and 'i' and 'l' need to be banned as well, because a san-serif uppercase I looks a lot like a san-serif lowercase l. (In fact, in the font I'm currently using, the two are pixel-identical). I don't see anybody calling for the banning of 'i' and 'l' in domain names due to that. It's interesting how some people are insisting that the IDN code has to be *perfect* and make it *totally* impossible to create a phishable spoof of a domain - but aren't willing to take the extra step of banning the characters in the Latin Ascii charset that are spoofable.
On Sat, Feb 11, 2012 at 11:13 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Sun, 12 Feb 2012 10:25:53 +0900, Masataka Ohta said:
Valdis.Kletnieks@vt.edu wrote: It's interesting how some people are insisting that the IDN code has to be *perfect* and make it *totally* impossible to create a phishable spoof of a domain - but aren't willing to take the extra step of banning the characters in the Latin Ascii charset that are spoofable. [snip]
There aren't really any characters in the latin ASCII charset that are so spoofable. 0 and O, |, I, l, and 1 do come close, depending on the font chosen. This is easily avoidable, because there are so few spoofable characters, you can easily just avoid using a spoofable one in your domain name, or register all variants. These are minor compared to the issues you get expanding the possible URL character sets to all unicode, through IDN support. The extended character sets available under IDN provide a large number of spoofable characters from various different charsets that are indistinguishable. For phishing to not be a serious risk, IDN implementations have to have some kind of security policy. A start would be: don't display IDN characters, unless they are within a character set the user is expected to be familiar with. For example, for a web browser that ships in North America, only the locally relevant IDN character sets should be enabled by default. If you should want to see IDN characters from Cyrillic character sets, or Chinese Ideographs, there should be a requirement you very deliberately install support for specific character set you need. Or install a localized browser that has the specific IDN charsets allowed by policy. There should also be a browser-enforced policy that different charsets cannot be mixed in the same domain name. Then any increase in phishing risk is limited to regions / language localized browsers where the character set with spoofable characters makes sense and is in common use. Ideally there should be a table of every pair of characters that "look somewhat similar to each other" in every character set, and every registrar ensuring appearance uniqueness for every new domain registration. -- -JH
Valdis.Kletnieks@vt.edu wrote:
Doesn't actually matter, because the .ua registry isn't allowing Greek Gamma or Latin-E-with-diaresis, in domain names.
Such local conventions have nothing to do with internationalization.
But quite frankly, turning off IDN doesn't fix that problem - greekbank.gr is spoofable by greekbank.ua and greekbank.com.
The problem is greekbank.gr is spoofable as greekbank.gr.
Is a Russian word containing no unique (unique to ASCII) Cyrillic characters encoded as Latin character using ASCII, even though a Russian word containing unique (whatever unique means) Cyrillic character encoded as Cyrillic characters?
No, it means you get to pick 'all-latin-chars.ua' or 'all-cyrillic-chars.ua'. And due to the requirement that a cyrillic name have a special char in it, you can's spoof an all-latin-chars.ua name.
That "a cyrillic name have a special char in it" makes it impossible to have a Cyrillic representation of an Ukrainian word containing no special chars and is impractical.
The only protection is to disable IDN.
You also have to ban the use of numbers in domain names, because you need to prevent people being tricked by micros0ft.com and m1crosoft.com.
No, the simple solution against such a simple problem is to use proper font, because all the people know that '0' and 'o' are different characters and treat them differently. Masataka Ohta
On Sun, 12 Feb 2012 16:59:36 +0900, Masataka Ohta said:
The problem is greekbank.gr is spoofable as greekbank.gr.
That would be the .gr registry's problem then. They could take the same solution as the .ua registry -force lowercase and allow all-latin or all-greek names. Oh, what do you know... they *do* do something similar. https://grweb.ics.forth.gr/tomcat_docs/AP592_012_2011_.pdf See page 5 and 6, in particular: 8. Any [.gr] Domain Names that are homographs of a [.gr] Domain Name already assigned shall be automatically reserved for the Holder of the above assigned [.gr] Domain Name and shall be activated following the Holder's submission of an activation declaration to the Registry. So how do you spoof greekbank.gr with greekbank.gr under those rules?
No, the simple solution against such a simple problem is to use proper font, because all the people know that '0' and 'o' are different characters and treat them differently.
Well then, if all that's required is a "proper font", what is the problem with your Saitoh families? You said they were "represented by 4 similar but different characters, which is distinguished by people named "Saitoh" but not distinguished by most others," Why can't *they* use a "proper font" that makes the difference between the 4 characters recognizable? After all, *they* know the 4 characters are different and can treat them differently, right? (And no, it's *not* "different for kanji" - it's the exact same problem and you know it. In both cases, (I/l and your Sai issue), the problem is similar glyphs. Don't bother replying to suggest a fix for the lower-l/upper-I issue unless the *same* fix applies to your Sai issue).
Valdis.Kletnieks@vt.edu wrote:
The problem is greekbank.gr is spoofable as greekbank.gr.
That would be the .gr registry's problem then.
As it is the problem of IDN, same problem exist everywhere.
They could take the same solution as the .ua registry -force lowercase and allow all-latin or all-greek names.
DNS does not allow .ua registry force lowercase for ASCII.
So how do you spoof greekbank.gr with greekbank.gr under those rules?
I merely used your example.
Well then, if all that's required is a "proper font", what is the problem with your Saitoh families?
All that's required is a "proper font" for ASCII. Beyond ASCII, you almost automatically loss. For example, in ISO8859-1 context, uppercase of 'y' with diaeresis is not 'Y' with diaeresis, because there is no 'Y' with diaeresis in ISO8859-1, which is bad enough. So, I can understand your attempt to insist on lowercase, but it does not work because DNS does not allow it. Masataka Ohta
2012/2/12 Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>:
Valdis.Kletnieks@vt.edu wrote: [snip] So, I can understand your attempt to insist on lowercase, but it does not work because DNS does not allow it. [snip]
Not exactly... DNS is case-insensitive when you are talking about 7-bit ASCII; the set of alphabetic characters that can appear in a DNS label; with no punycode. IDN means that non-ASCII characters are represented using punycode. As soon as you have a browser parsing punycode stuff, any string containing unicode characters has a unique punycode encoding / RFC 3491 / RFC 3492. The symbols represented in the punycode encodings are not case sensitive. Uppercase A-Z vs Lowercase a-z in the generalized variable-length integers are not distinct, the punycode representation itself cannot really be case sensitive, but the codepoint represented by the encoding, the result of decoding the punycode is case-preserving. -- -JH
DNS is case-insensitive when you are talking about 7-bit ASCII
< pedantry > dns itself is purely eight bit transparent. one can even have a dot as a non-separator. p.r.c could be a tld. it's strictly length/value. of course, everyone and their dog has placed restrictions on it for this use or that. randy
On Sun, Feb 12, 2012 at 11:36 PM, Randy Bush <randy@psg.com> wrote:
DNS is case-insensitive when you are talking about 7-bit ASCII < pedantry > dns itself is purely eight bit transparent. one can even have a dot as a non-separator. p.r.c could be a tld. it's strictly length/value.
That's true, but there is no standard character representation for octet values 128 - 255. If you use them in a DNS record, they are just binary values that don't refer to a specific printable symbol. Only octets in the range from 65 to 90 (uppercase) and 977 to 122 (lowercase) have a case equivalent for DNS resolution. And IDN uses 7-bit ASCII DNS records. -- -JH
dns itself is purely eight bit transparent. one can even have a dot as a non-separator. p.r.c could be a tld. it's strictly length/value. That's true, but there is no standard character representation for octet values 128 - 255.
utf-8 is the one used in the ietf community.
Only octets in the range from 65 to 90 (uppercase) and 977 to 122 (lowercase) have a case equivalent for DNS resolution.
dns resolution is eight bit clear. randy
In message <m2ipjbmgbq.wl%randy@psg.com>, Randy Bush writes:
dns itself is purely eight bit transparent. =A0one can even have a dot as a non-separator. =A0p.r.c could be a tld. =A0it's strictly length/value. That's true, but there is no standard character representation for octet values 128 - 255.
utf-8 is the one used in the ietf community.
I challenge you to find a RFC that say it is UTF-8.
Only octets in the range from 65 to 90 (uppercase) and 977 to 122 (lowercase) have a case equivalent for DNS resolution.
dns resolution is eight bit clear.
It may be 8 bit clear but only 0-127 have defined meaning. 128-255 may be UTF-8 but they could equally be ISO-LATIN-*.
randy -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Mon, Feb 13, 2012 at 05:21:02PM +1100, Mark Andrews <marka@isc.org> wrote a message of 25 lines which said:
utf-8 is the one used in the ietf community.
I challenge you to find a RFC that say it is UTF-8.
Challenge taken. RFC 2277, "IETF Policy on Character Sets and Languages", section 3.1, "Protocols MUST be able to use the UTF-8 charset [...] Protocols MAY specify, in addition, how to use other charsets [something DNS does not do, so it must be UTF-8]" RFC 5198 is a good reading, too. So, basically, in IETF land, if the encoding is not specified, it is UTF-8.
On Wed, 15 Feb 2012 10:44:38 +0100, Stephane Bortzmeyer said:
Challenge taken.
RFC 2277, "IETF Policy on Character Sets and Languages", section 3.1, "Protocols MUST be able to use the UTF-8 charset [...] Protocols MAY specify, in addition, how to use other charsets [something DNS does not do, so it must be UTF-8]"
(ooh.. an RFC lawyering fight. Goody goody, haven't had one in a while.. :) That requires overlooking the minor detail that the DNS RFC predates that by quite some time, and there's no combination of RFCs 2119 and 2277 that mandates retrofitting grandfathered protocols by fiat. It also requires overlooking the fact that 2277 is a BCP, not an Internet Standard, and as such isn't itself binding, merely A Good Idea. Nice try though. ;)
Valdis.Kletnieks@vt.edu writes:
On Wed, 15 Feb 2012 10:44:38 +0100, Stephane Bortzmeyer said:
Challenge taken.
RFC 2277, "IETF Policy on Character Sets and Languages", section 3.1, "Protocols MUST be able to use the UTF-8 charset [...] Protocols MAY specify, in addition, how to use other charsets [something DNS does not do, so it must be UTF-8]"
(ooh.. an RFC lawyering fight. Goody goody, haven't had one in a while.. :)
That requires overlooking the minor detail that the DNS RFC predates that by quite some time, and there's no combination of RFCs 2119 and 2277 that mandates retrofitting grandfathered protocols by fiat.
It also requires overlooking the fact that 2277 is a BCP, not an Internet Standard, and as such isn't itself binding, merely A Good Idea.
Nice try though. ;)
Valdis, re-read the original assertion and challenge. Your attempt at RFC lawyering appears to be "Experimental" <grin> -r
In message <86mx8kqpy7.fsf@seastrom.com>, "Robert E. Seastrom" writes:
Valdis.Kletnieks@vt.edu writes:
On Wed, 15 Feb 2012 10:44:38 +0100, Stephane Bortzmeyer said:
Challenge taken.
RFC 2277, "IETF Policy on Character Sets and Languages", section 3.1, "Protocols MUST be able to use the UTF-8 charset [...] Protocols MAY specify, in addition, how to use other charsets [something DNS does not do, so it must be UTF-8]"
(ooh.. an RFC lawyering fight. Goody goody, haven't had one in a while.. :)
That requires overlooking the minor detail that the DNS RFC predates that by quite some time, and there's no combination of RFCs 2119 and 2277 that mandates retrofitting grandfathered protocols by fiat.
It also requires overlooking the fact that 2277 is a BCP, not an Internet Standard, and as such isn't itself binding, merely A Good Idea.
Nice try though. ;)
Valdis, re-read the original assertion and challenge.
Your attempt at RFC lawyering appears to be "Experimental" <grin>
The Internationalised DNS uses IDNA suite of RFC's to encode UTF into A-labels. Before deciding to go the IDNA route, treating DNS labels as UTF-8 was discussed, evaluated and rejected. DNS labels are length tagged binary blobs with case folding of the 7 bit ascii values 'a'-'z' when performing lookups. If a server is fully compliant (and I don't think any is) answers should be returned in a case preserving manner, including owner names. The intent of RFC 1035 was to be able to use the DNS to store and retrieve binary data using binary keys. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 2/15/12 8:32 AM, Mark Andrews wrote:
... Before deciding to go the IDNA route, treating DNS labels as UTF-8 was discussed, evaluated and rejected.
well, sort of. we started with "idn" as a wg label. the smtp weenies opined that they'd never have a flag day and anything other than a boot encoding in LDH would harm LDH limited mailers, so ... the code point problem (or problems) was moved out of "infrastructure" and into "applications", so the work product was labeled "idna", which the successor wg had no alternative except to follow the "in a" set of dependencies and assumptions. as you observed, labels are length tagged binary blobs, and where the blobs consist of 7 bit ascii values in the 'a'-'z' range, case folding is performed in lookup. what happens outside of that range is a path not taken, though i tried in 2929 to leave that open for future work, the sentence which read "text labels can, in fact, include any octet value including zero octets but most current uses involve only [US-ASCII]." was, if memory serves, proposed by a co-author to have been more restrictive. i agree with the "rejected" statement, the "evaluated" and even the "discussed" overstate the room available after the smtp weenies weighed in on what was permissible in headers. -e
On Sun, Feb 12, 2012 at 09:36:54PM -0800, Randy Bush wrote:
DNS is case-insensitive when you are talking about 7-bit ASCII
< pedantry >
dns itself is purely eight bit transparent. one can even have a dot as a non-separator. p.r.c could be a tld. it's strictly length/value.
of course, everyone and their dog has placed restrictions on it for this use or that.
randy
ah, the good'ol days. ^g.net as an early attempt for the visually impaired lasted for a couple months. about the same time you received your IPv4 /33 /bill
Jimmy Hess wrote:
As soon as you have a browser parsing punycode stuff, any string containing unicode characters has a unique punycode encoding / RFC 3491 / RFC 3492.
Labels (not "any string") which happens to be pure ASCII are still case insensitive, which is DNS. Note that, according to Valdis; : (The actual policy for the .UA registrar is more subtle. : They *do* in fact allow "U+0441 Cyrillic Small Letter ES" : which is visually a C to us Latin-glyph users. However, : they require at least one character that's visually unique : to Cyrillic in the domain name. They also don't allow ; mixed Cyrillic/Latin scripts in one domain name). a label (not "domain name") of a Ukrainian word all the characters of which have shapes identical to some ASCII characters can only be represented using ASCII characters only. Masataka Ohta
Oh, and 'i' and 'l' need to be banned as well, because a san-serif uppercase I looks a lot like a san-serif lowercase l. (In fact, in the font I'm currently using, the two are pixel-identical).
I don't see anybody calling for the banning of 'i' and 'l' in domain names due to that.
The very first phishing message I ever saw was from paypa1.com. --Steve Bellovin, https://www.cs.columbia.edu/~smb
Nice. Basically, unless the TLD registrar has a public policy that basically says "We don't allow names with cyrillic C to collide with MICROSOFT", their hostnames all get displayed as xn--gobbledygook.
More or less. ICANN has been wrestling with the lookalike character issue in domain names for about a decade. I think it's fair to say that everyone agrees that all solutions are less than totally satisfactory. R's, John
The DNS "industry" is putting us a long way from when RFC 2826 was written. Christian On 12 Feb 2012, at 01:31, John Levine wrote:
Nice. Basically, unless the TLD registrar has a public policy that basically says "We don't allow names with cyrillic C to collide with MICROSOFT", their hostnames all get displayed as xn--gobbledygook.
More or less. ICANN has been wrestling with the lookalike character issue in domain names for about a decade. I think it's fair to say that everyone agrees that all solutions are less than totally satisfactory.
R's, John
The DNS "industry" is putting us a long way from when RFC 2826 was written.
That's true, but you can't just blow off the majority of people in the world who use languages that you can't write in the ASCII character set. It's a hard problem. I wouldn't say that ICANN's approach has been optimal, but I also wouldn't say there's an obvious solution they've missed. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
Heck, even Klingon made it to the private UTF-8 registry, http://en.wikipedia.org/wiki/Klingon_writing_systems :) Jeff
Neil Harris wrote:
Techniques to deal with this sort of spoofing already exist: see
http://www.mozilla.org/projects/security/tld-idn-policy-list.html
It does not make sense that .COM allows Cyrillic characters: http://www.iana.org/domains/idn-tables/tables/com_cyrl_1.0.html i script of a domain name is Cyrillic. Domain names do not have such property as script. Is the following domain name: CCC.COM Latin or Cyrillic?
for one quite effective approach.
The only reasonable thing to do is to disable so called IDN. Masataka Ohta PS Isn't it obvious from the page you referred that IDN is not internationalization but an uncoordinated collection of poor localizations?
On 12/02/12 00:09, Masataka Ohta wrote:
Neil Harris wrote:
Techniques to deal with this sort of spoofing already exist: see
http://www.mozilla.org/projects/security/tld-idn-policy-list.html It does not make sense that .COM allows Cyrillic characters:
http://www.iana.org/domains/idn-tables/tables/com_cyrl_1.0.html
i script of a domain name is Cyrillic.
Domain names do not have such property as script.
Is the following domain name:
CCC.COM
Latin or Cyrillic?
for one quite effective approach. The only reasonable thing to do is to disable so called IDN.
Masataka Ohta
PS
Isn't it obvious from the page you referred that IDN is not internationalization but an uncoordinated collection of poor localizations?
I'm not a flag-waver for IDN, so much as a proponent of ways to make IDN safer, given that it already exists. Lots of people have thought about this quite carefully. See RFC 4290 for a technical discussion of the thinking behind this policy, and RFC 5992 for a policy mechanism designed to resolve the problem you raised in your example above. You will notice that the .com domain does not appear on the Mozilla IDN whitelist. -- N.
yes, domain names that cannot be typed in with any keyboard/charset on any computer out there, excellent idea, devide and conquerer, i wonder who came up with that idiotic plan again, probably the ITU or one of their infiltrants in icann. how about, we simply don't code any software or adjust any platforms to support it, if nobody uses it, no problem :P (or just deliberately break it as its nothing more than a "devide and conquerer" attempt of the UN anyway ;) On Sun, 12 Feb 2012, Neil Harris wrote:
On 12/02/12 00:09, Masataka Ohta wrote:
Neil Harris wrote:
Techniques to deal with this sort of spoofing already exist: see
http://www.mozilla.org/projects/security/tld-idn-policy-list.html It does not make sense that .COM allows Cyrillic characters:
http://www.iana.org/domains/idn-tables/tables/com_cyrl_1.0.html
i script of a domain name is Cyrillic.
Domain names do not have such property as script.
Is the following domain name:
CCC.COM
Latin or Cyrillic?
for one quite effective approach. The only reasonable thing to do is to disable so called IDN.
Masataka Ohta
PS
Isn't it obvious from the page you referred that IDN is not internationalization but an uncoordinated collection of poor localizations?
I'm not a flag-waver for IDN, so much as a proponent of ways to make IDN safer, given that it already exists.
Lots of people have thought about this quite carefully. See RFC 4290 for a technical discussion of the thinking behind this policy, and RFC 5992 for a policy mechanism designed to resolve the problem you raised in your example above.
You will notice that the .com domain does not appear on the Mozilla IDN whitelist.
-- N.
On 2/11/12 19:34 , Sven Olaf Kamphuis wrote:
yes, domain names that cannot be typed in with any keyboard/charset on any computer out there, excellent idea, devide and conquerer, i wonder who came up with that idiotic plan again, probably the ITU or one of their infiltrants in icann.
If it's worth shoveling blame indiscriminately it's worth informing yourself a little about the timeline and the actors involved. http://en.wikipedia.org/wiki/Internationalized_domain_name
how about, we simply don't code any software or adjust any platforms to support it, if nobody uses it, no problem :P
(or just deliberately break it as its nothing more than a "devide and conquerer" attempt of the UN anyway ;)
On Sun, 12 Feb 2012, Neil Harris wrote:
On 12/02/12 00:09, Masataka Ohta wrote:
Neil Harris wrote:
Techniques to deal with this sort of spoofing already exist: see
http://www.mozilla.org/projects/security/tld-idn-policy-list.html It does not make sense that .COM allows Cyrillic characters:
http://www.iana.org/domains/idn-tables/tables/com_cyrl_1.0.html
i script of a domain name is Cyrillic.
Domain names do not have such property as script.
Is the following domain name:
CCC.COM
Latin or Cyrillic?
for one quite effective approach. The only reasonable thing to do is to disable so called IDN.
Masataka Ohta
PS
Isn't it obvious from the page you referred that IDN is not internationalization but an uncoordinated collection of poor localizations?
I'm not a flag-waver for IDN, so much as a proponent of ways to make IDN safer, given that it already exists.
Lots of people have thought about this quite carefully. See RFC 4290 for a technical discussion of the thinking behind this policy, and RFC 5992 for a policy mechanism designed to resolve the problem you raised in your example above.
You will notice that the .com domain does not appear on the Mozilla IDN whitelist.
-- N.
On Feb 11, 2012, at 10:57 PM, Joel jaeggli wrote:
On 2/11/12 19:34 , Sven Olaf Kamphuis wrote:
yes, domain names that cannot be typed in with any keyboard/charset on any computer out there, excellent idea, devide and conquerer, i wonder who came up with that idiotic plan again, probably the ITU or one of their infiltrants in icann.
If it's worth shoveling blame indiscriminately it's worth informing yourself a little about the timeline and the actors involved.
You mean he's serious? I thought he was just being an ironic troll... Regards, -drc
as if it wasn't annoying enough already that some n00bs are using URI's with characters you can't type in (and in most cases don't even display correctly), icann has a better idea! hostnames you can't type in! all those struggeling regimes that want to keep local control over our internets are gonna be so proud of them :P (and that despite the fact that it's perfectly well possible to write -any language out there- in the first 7 bits of ascii) yay, a step back in time, everyone back to their cave and write on the wall with a piece of stone in characters nobody can read! so far for progress... we used to develop stuff so that people could communicate with one another, whatever went wrong, when did it move to "preventing people from communicating with one another"... i don't have keyboards with a million or so keys on it, do you? and no, i don't know the alt-codes for weird russian or japanese crap. if we wanted local shit only, we could just have stuck with tv and radio and telephones and fax machines. so; we're not implementing any of that, we'll deliberately make any software we produce go nuts on it and cause errors all over the place, and we strongly urge any nerd out there to do exactly the same. On Sun, 12 Feb 2012, Neil Harris wrote:
On 12/02/12 00:09, Masataka Ohta wrote:
Neil Harris wrote:
Techniques to deal with this sort of spoofing already exist: see
http://www.mozilla.org/projects/security/tld-idn-policy-list.html It does not make sense that .COM allows Cyrillic characters:
http://www.iana.org/domains/idn-tables/tables/com_cyrl_1.0.html
i script of a domain name is Cyrillic.
Domain names do not have such property as script.
Is the following domain name:
CCC.COM
Latin or Cyrillic?
for one quite effective approach. The only reasonable thing to do is to disable so called IDN.
Masataka Ohta
PS
Isn't it obvious from the page you referred that IDN is not internationalization but an uncoordinated collection of poor localizations?
I'm not a flag-waver for IDN, so much as a proponent of ways to make IDN safer, given that it already exists.
Lots of people have thought about this quite carefully. See RFC 4290 for a technical discussion of the thinking behind this policy, and RFC 5992 for a policy mechanism designed to resolve the problem you raised in your example above.
You will notice that the .com domain does not appear on the Mozilla IDN whitelist.
-- N.
On Sun, 12 Feb 2012 03:47:24 GMT, Sven Olaf Kamphuis said:
(and that despite the fact that it's perfectly well possible to write -any language out there- in the first 7 bits of ascii)
And it's *equally* possible to write "any language out there" using a 7-bit encoding of the Cyrillic character set. Let me know how you'd enjoy doing that. Oh, that would suck because Cyrillic isn't very similar to your native character set? Welcome to the way the vast majority of the world feels.
Valdis.Kletnieks@vt.edu wrote:
(and that despite the fact that it's perfectly well possible to write -any language out there- in the first 7 bits of ascii)
Yes, any language including FORTRAN.
And it's *equally* possible to write "any language out there" using a 7-bit encoding of the Cyrillic character set.
Yes, any language including FORTRAN, because KOI-7, a 7-bit encoding of the Cyrillic character set, includes all the uppercase Latin characters.
Oh, that would suck because Cyrillic isn't very similar to your native character set? Welcome to the way the vast majority of the world feels.
See how the vast majority of the world feels. http://en.wikipedia.org/wiki/ISO/IEC_646 Since the portion of ISO/IEC 646 shared by all countries (the "invariant set") specified only those letters used in the ISO basic Latin alphabet, Masataka Ohta
Neil Harris wrote:
I'm not a flag-waver for IDN, so much as a proponent of ways to make IDN safer, given that it already exists.
It's like trying to make DES safer.
Lots of people have thought about this quite carefully.
Not at all. They (including some Japanese) just wished IDN work ignoring technical reality.
See RFC 4290 for a technical discussion of the thinking behind this policy,
Technically speaking, there are several sets of frequently used different but similar Japanese characters most people do not distinguish so vigorously. For example, "Sai" of "Saitoh", the tenth most frequent Japanese family name, is represented by 4 similar but different characters, which is distinguished by people named "Saitoh" but not distinguished by most others, which means phishing is unavoidable. That is, RFC4290 covering such Japanese characters is not technical from the beginning.
and RFC 5992 for a policy mechanism designed to resolve the problem you raised in your example above.
It is nothing more than a political statement, because there is no reasonable way to use tables in Appendix A.
You will notice that the .com domain does not appear on the Mozilla IDN whitelist.
Which means IDN can not be "Internationalized" at all and selling IDN is nothing more than a fraud. Masataka Ohta
On Friday 10 February 2012 17:24, Landon Stewart wrote:
My $0.02 on this issue is if the message is rich text I hover over the link and see where it actually sends me. If I don't know what that link is then I don't click it.
Oh really? How about trying this.... Go to Google and search "is my url safe": http://www.google.com/search?q=is+my+url+safe Now hover over that second link reportedly to faq.ssl.com and look at what your browser reports: http://faq.ssl.com/article.aspx?id=10068 Now look at the page code or copy/paste the URL somewhere else... Where does that link really go? .... http://www.google.com/url?q=http://faq.ssl.com/article.aspx%3Fid%3D10068&sa=U&ei=JcI1T_DRKJDXiAKauoSvCg&ved=0CBgQFjAB&usg=AFQjCNHSmrhtgWQczEe1j0LhdMdUW5x4LA So much for looking at what mouse-over shows.... Adrian
On Fri, 10 Feb 2012 16:24:11 PST, Landon Stewart said:
I don't click it. Not sure how long it's going to take, probably a generation, for people to use some sense before mindlessly clicking on stuff.
Only if you find a way to keep more idiots from being born. :) I don't think anybody wants to go there. At least not on this list.
Unfortunately that's not under control of those businesses. This plain text email you sent comes across with clickable mailto and http links in your signature in most modern email clients despite you having sent it in plain text. "Helpful" email program defaults won't force people to copy and paste the URL. They just create the hyperlink for people based on the pattern in the plain text message. It seems anything beginning with www or http(s):// will be converted to a clickable link out of convenience to the user. It's always that endless struggle of security vs. convenience... -Vinny -----Original Message----- From: Landon Stewart [mailto:lstewart@superb.net] Sent: Friday, February 10, 2012 7:24 PM To: Brandon Butterworth Cc: nanog@nanog.org Subject: Re: Dear RIPE: Please don't encourage phishing On 10 February 2012 16:09, Brandon Butterworth <brandon@rd.bbc.co.uk> wrote:
So it's necessary to throw the baby out with the bathwater, and tell them never to click on a link...
That baby was ugly anyway
HAHAHA. My $0.02 on this issue is if the message is rich text I hover over the link and see where it actually sends me. If I don't know what that link is then I don't click it. Not sure how long it's going to take, probably a generation, for people to use some sense before mindlessly clicking on stuff. Banks and businesses that keep sensitive information in a protected area on the web for you should start sending messages in PLAIN TEXT so you have to copy/paste the link if you don't already have it book marked or don't want to type it. Sure it's not all flashy and there's no nice pictures and junk but if you get an email from your bank that's not in plain text and contains hyperlinks then you'll know it's fake before you even read it. --- Landon Stewart <lstewart@superb.net <mailto"LStewart@Superb.Net>> Manager of Systems and Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": www.superb.net
Unfortunately that's not under control of those businesses. This plain text email you sent comes across with clickable mailto and http links in your signature in most modern email clients despite you having sent it in plain text. "Helpful" email program defaults won't force people to copy and paste the URL. They just create the hyperlink for people based on the pattern in the plain text message. It seems anything beginning with www or http(s):// will be converted to a clickable link out of convenience to the user. It's always that endless struggle of security vs. convenience...
At least it is what is says, and the effect is precisely the same as if one copied and pasted the link into the browser. What is truly evil is non text/plain email. Anyone who permits or assists in the rendering of non-plaintext email deserves whatever befalls them -- and they should not be permitted zero-liability for their stupidity and ignorance. They end-user is of course entitled to cross-claim against the manufacturer of the defective system or device which rendered the message in a deceptive way (such as Dell and Microsoft in particular). --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
On 2/11/2012 4:37 PM, Keith Medcalf wrote:
Unfortunately that's not under control of those businesses. This plain text email you sent comes across with clickable mailto and http links in your signature in most modern email clients despite you having sent it in plain text. "Helpful" email program defaults won't force people to copy and paste the URL. They just create the hyperlink for people based on the pattern in the plain text message. It seems anything beginning with www or http(s):// will be converted to a clickable link out of convenience to the user. It's always that endless struggle of security vs. convenience...
At least it is what is says, and the effect is precisely the same as if one copied and pasted the link into the browser.
What is truly evil is non text/plain email. Anyone who permits or assists in the rendering of non-plaintext email deserves whatever befalls them -- and they should not be permitted zero-liability for their stupidity and ignorance.
They end-user is of course entitled to cross-claim against the manufacturer of the defective system or device which rendered the message in a deceptive way (such as Dell and Microsoft in particular).
The average person won't know that "it is what it says" if it's possible for it not to be... which I think is what you're driving at with eliminating that as a possibility. And the effect is the same, but the time to do it is different. I wouldn't want to have to use web sites with no hyperlinks and I was expected to just copy and paste every URL I wanted to follow into the address bar. However, the vast majority of the Internet population (and human beings in general) like aesthetically pleasing things and therefore don't want to upgrade to mutt and lynx to be safe on the Internet. HTML based email looks much better despite embedded hidden <evil> tags. All recent email clients I've come across give you anti-phishing warnings in one way or another if the URL does not match the actual link. I honestly can't remember the last time I've seen a phishing email because they are so easy to detect before they even get to your inbox. Sure, you could also keep the HTML and disable the links (which I've seen done), but then you inconvenience people. Things take too long as it is now anyway despite the constant advancements we see constantly. We need to speed technology up more and make them easier AND safer. Technology needs to be unobtrusive to the end user and get out of their way. I personally don't believe the mantra of stripping away technology to solve problems rather than applying technology and advancing standards is the answer just because technology makes something dangerous for the average consumer. Despite all the car fatalities on a yearly basis and the constant safety advancements we have in the auto industry, I have never heard people say we should get rid of cars and go back to horses. Of course scam emails are much more prevalent than car fatalities by far, but they're also less serious. Most of the younger generation I know doesn't even use email. They have it as a formality because things require it and exchange everything via Facebook or video chat or IM... which simply means this concern over the trickery of immoral scammers on the average unsuspecting person will just shift mediums as has throughout history. It's already prevalent on these mediums now. Not sure what the jab at Dell was specifically other than the email address I posted from originally. As far as I have seen, Dell doesn't make email clients. That's like someone holding Sony/Samsung/LG liable because their TV showed them a TV program they didn't want to see. Anyway, just my $0.02 wrapped in rambling from a tired mind. Sorry if some of this didn't make sense as a result. :) -Vinny P.S. I prefer plain-text email. ;)
On Sun, Feb 12, 2012 at 04:44:13AM -0500, Vinny Abello wrote:
All recent email clients I've come across give you anti-phishing warnings in one way or another if the URL does not match the actual link.
Which is great, but doesn't help you if the URL and the link are: http://firstnationalbank.example.com because a significant number of users will only see "firstnationalbank" and ".com". That's why I recommend that banks et.al. don't put *any* URLs in their messages. If they make this an explicit policy and pound it into the heads of their customers that ANY message containing a URL is not from them, and that they should always use their bookmarks to get to the bank's site, then they're training their customers to be phish-resistant. ---rsk
That's why I recommend that banks et.al. don't put *any* URLs in their messages. If they make this an explicit policy and pound it into the heads of their customers that ANY message containing a URL is not from them, and that they should always use their bookmarks to get to the bank's site, then they're training their customers to be phish-resistant.
they do, and the next thing you know, someone in marketing sends out an email with an url -anyway-. considering the fact that banks don't seem to like to be contacted by emails nor get replies (noreply@...) i'd strongly suggest them not to use crappy obsolete SMTP at all but rather present the users with their messages they don't want to distribute by paper mail -after- logging into their online banking system, where they can use all the html, links, flash *kuch* etc they want.
---rsk
btw, i'm quite sure that -banks- of all things have the resources to just take the transaction part for consumers -off their pcs- and simply send them a dedicated device with an ethernet port to do the transactions on. the same way they do in shops. no more bothering with "omg what if they click a link, get phished and end up in the transaction interface", as there simply won't be a web based transaction interface. guess the "its not allowed to cost anything" mentality of banks towards the internet is mostly gone (About time too ;) so they could consider other options besides "using the hardware that's allready there and owned by the customer (and full of virusses and spyware ;)" -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven@cb3rob.net ========================================================================= <penpen> C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Sun, 12 Feb 2012, Rich Kulawiec wrote:
On Sun, Feb 12, 2012 at 04:44:13AM -0500, Vinny Abello wrote:
All recent email clients I've come across give you anti-phishing warnings in one way or another if the URL does not match the actual link.
Which is great, but doesn't help you if the URL and the link are:
http://firstnationalbank.example.com
because a significant number of users will only see "firstnationalbank" and ".com".
That's why I recommend that banks et.al. don't put *any* URLs in their messages. If they make this an explicit policy and pound it into the heads of their customers that ANY message containing a URL is not from them, and that they should always use their bookmarks to get to the bank's site, then they're training their customers to be phish-resistant.
---rsk
In article <Pine.LNX.4.64.1202121919390.10731@a84-22-97-10.cb3rob.net> you write:
btw, i'm quite sure that -banks- of all things have the resources to just take the transaction part for consumers -off their pcs- and simply send them a dedicated device with an ethernet port to do the transactions on.
More likely USB, but yes, a doozit with a small screen to display the amount and recipient of a transaction and a verification code you type in, and sufficient crypto to set up a secure channel back to the bank would fix a lot of phishing. I don't understand bank security at all. HSBC recently sent me a Digipass 270 with a 12 button keyboard and a one-line display that is apparently able to do signatures, but all they use it for is a PIN. That's helpful against password theft, but not MITM. R's, John
On 2/12/2012 1:19 PM, Rich Kulawiec wrote:
On Sun, Feb 12, 2012 at 04:44:13AM -0500, Vinny Abello wrote:
All recent email clients I've come across give you anti-phishing warnings in one way or another if the URL does not match the actual link.
Which is great, but doesn't help you if the URL and the link are:
http://firstnationalbank.example.com
because a significant number of users will only see "firstnationalbank" and ".com".
That's why I recommend that banks et.al. don't put *any* URLs in their messages. If they make this an explicit policy and pound it into the heads of their customers that ANY message containing a URL is not from them, and that they should always use their bookmarks to get to the bank's site, then they're training their customers to be phish-resistant.
Yes, very true. I unfortunately see average people fall for these types of things all the time. Ultimately, the issue is getting the end user educated. However, I've also seen users get a message drilled into their heads for 10 years that an email admin will never ask for their passwords, yet they eagerly give them away to some random scammer that says they need their password or their account will be shut off, signed by "the email team"... and suddenly their email account is spewing spam from random IP addresses all over the net. <sigh> The weakest link is ultimately the person behind the device. We're attempting to make technology fix stupid, which is often harder for the people designing the technology. They would never think sticking their hand down a garbage disposal is a good idea, but there are people out there that do this. :( Likewise, a person wouldn't click on a link if it's blatantly obvious the link doesn't point to the real web site, right? :) Obviously no. To be very effective, security design needs to assume the biggest threat to the security of anything is the person on the good side of the fence who will open the gate. Lately, I get calls on a weekly basis from people trying to steal my credit card from me. If I have time I like to have fun with them, eating up their time so they have less of it to scam people who don't know any better. (Look on Youtube for people doing this. It's hilarious). These scammers have been around for at least 5 years or longer and nobody has yet fixed this problem, which is also astounding. As a result, customers who don't recognize the scam get their credit card whacked with random charges because they didn't think anything was wrong with giving away their credit card info and social security number to a random stranger who calls them and claims to be able to lower their interest rate. So at the same time making people aware the real emails will not contain links, banks should be doing a better job telling people not to give away their credit card info to anyone in a situation similar to this. It should be better handled by all banks and companies in genereal as a global security education process. I don't believe it should be limited just to email or Internet related usage of the bank or company's resources. I'm probably not giving people enough credit, but social engineering is likely the most effective hacking technique that exists because it targets the weakest link and often works. That's currently the easiest thing to target because security has improved so much over the years on the technological end. I'm not sure about others, but the most prevalent security threats I see today are vastly different than the ones from ten to fifteen years prior. -Vinny
What is truly evil is non text/plain email.
Have we fallen through a time warp into 1996? R's, John -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
What is truly evil is non text/plain email.
Have we fallen through a time warp into 1996?
Evidently yes. Look, it's a known-not-to-work SMTP callback:
<kmedcalf@dessus.com>: Connected to 69.172.205.65 but sender was rejected. Remote host said: 578 johnl@iecc.com address rejected with reverse-check
-- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
participants (27)
-
Adrian -
bmanning＠vacation.karoshi.com -
Brandon Butterworth -
chris -
Christian de Larrinaga -
David Conrad -
Eric Brunner-Williams -
Javier Henderson -
Jeff Kell -
Jimmy Hess -
Joel jaeggli -
John Levine -
John R. Levine
-
Keith Medcalf -
Landon Stewart -
Mark Andrews -
Masataka Ohta -
Neil Harris -
Randy Bush -
Rich Kulawiec -
Robert E. Seastrom -
Stephane Bortzmeyer -
Steven Bellovin -
Sven Olaf Kamphuis -
Valdis.Kletnieks＠vt.edu -
Vinny Abello -
Vinny_Abello＠Dell.com