- From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Date: Wed, 25 Nov 2009 19:25:55 +0900
- To: Shawn Steele <Shawn.Steele@microsoft.com>
- CC: Larry Masinter <masinter@adobe.com>, "PUBLIC-IRI@W3.ORG" <PUBLIC-IRI@w3.org>, Pete Resnick <presnick@qualcomm.com>, Ted Hardie <ted.ietf@gmail.com>
Hello Shawn, On 2009/11/25 4:44, Shawn Steele wrote: > We're getting WAY off topic. I agree. > Is there a BCP for IRI security? No. The IETF has a tradition of putting security considerations in the main document, not as a separate document. >> So trying to spoof the path is indeed another technique, but in most >> cases, it doesn't work because there is a single authority in control of >> all the paths on the same domain. So that's why I'm saying that the main >> place where spoofing can happen in IRIs is the IDN part. > > But that only works for you because you know how paths work! Yes. I don't think we actually disagree. What you are saying is that spoofing because people don't look at IRIs/URIs at all is a much greater problem than spoofing with lookalikes and the like. I fully agree. What I am saying is that spoofing of IRIs with the domain name part is a much greater problem than spoofing with IRIs in the rest of the IRI. Overall, it's like you saying that one kilometer is bigger than one meter, and me saying that one millimeter is greater than one micrometer. (sorry I don't have a non-metric equivalent for these examples) Regards, Martin. > It's been pretty well demonstrated that the average user doesn't know those things, and, indeed, LEGITIMATE businesses even (mis?)use the system for their convenience or to outsource ads or mail lists or whatnot. > > Those of us with kids in this country are likely to know about a place called "Check E Cheese's". And it's a lot cheaper with a coupon. If I visit http://www.chuckecheese.com/, then I'll have the opportunity to subscribe to an email list and get spammed with coupons periodically. Those coupons are sent from "Chuck E. Cheese's [cecmail@replies.cecentertainment.com]". There's absolutely no way to verify that these are connected. Ruby's is worse. Rubys.com sends mail from rubys.fbmta.com with links to the same (rubys.fbmta.com). Toysrus.com gets you to toyrus.shoplocal.com. I've also seen them in the form client.adfirm.com or adfirm.com/client, no clue if the client/adfirm relationship is legitimate. Lots of online stores use a 3rd party for checkout. At least I can recognize yahoo or paypal, but for others I'd have to make a leap of faith. > > Heck, I got an internal survey about Microsoft which some team had contracted out to an external vendor. No clue if it was a legitimate internal survey or someone phishing for intelligence about Microsoft. The mail didn't even come from an internal address. (Yea, I contacted the group to find out if it was legit, but they were surprised I even bothered). > > Do you ever follow those links? I often do. Of course if it's a bank or its going to end up asking for payment or other info I usually end up retyping the original URL (toysrus.com instead of toysrus.shoplocal.com) and follow links from there, but would the average person bother? > > When users are trained that any sort of weird variation in the URL is OK, so long as it says my vendor in their somewhere, then there's not much we can do about it, and IDN is completely irrelevant so far as changing security goes. > > I used to try to contact marketing departments when I noticed that they sent customers to URLs that weren't obviously in their control, but they don't seem to care. Until that's fixed IDN homographs don't even come close to being interesting. I don't even think we can fix it because clearly they don't seem to care enough to follow a BCP for IRIs even if one existed. If I can't even get Microsoft security to be interested in this problem, how do we expect every retailer to bother? > > Note that in every one of these cases the domain could've been fixed. Instead of toysrus.shoplocal.com, there's no reason they couldn't have pointed shoplocal.toysus.com to their vendor's server and used that instead. Similarly the mail could be from vendor.client.com. My internal survey could've redirected from a trusted internal server to the external one. > > -Shawn > > > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp
Received on Wednesday, 25 November 2009 10:26:57 UTC