Feed aggregator

AOL Has a Security Hole, and It's Our Problem

CircleID - 6 hours 58 min ago

Two weeks ago I wrote about Yahoo's unfortunate mail security actions. Now it's AOL's turn, and the story, as best as I can piece it together, is not pretty.

Yahoo used an emerging system called DMARC, which was intended to fight phishing of often forged domains like paypal.com. A domain owner can publish a DMARC "reject" policy which, oversimplifying a little, tells the world that if mail with their name on the 'From:' line didn't come from their servers, it's not from them so you should reject it.

While this policy is fine for Paypal, it was bad news when Yahoo did it over the weekend a few weeks ago, because there is a lot of mail with 'yahoo.com' on the 'From:' line that doesn't come from Yahoo. The highest profile is discussion mailing lists, but there are others like newspaper mail-an-article buttons that put the address of the person sending the article on the 'From:' line, and various mail consolidation setups, like the one at Gmail that lets you collect mail from all your accounts in your Gmail inbox, and also send mail with the addresses of those accounts. (They check it's really you before they let you do it, of course.) All those now don't work reliably any more, when sending from a yahoo.com address, and as I explained in the previous article, cause considerable harm to innocent bystanders on other mail systems.

Now AOL just did the same thing, at least sending out a press release so we didn't have to reverse engineer what they did. But it's also now clear why Yahoo and AOL did this: it's a band-aid for big security problems. I've been getting a lot of spam from aol.com addresses of people I know, with other people I know on the 'To:' line. This means that the crooks were using the AOL user's address book. And when I look at the spam, most of it doesn't come from AOL, but instead from other ISPs such as Orange, a French phone company, which means that the horse has left the barn, the crooks have stolen the AOL users' address books and there's nothing AOL can do about it. I am hardly the only one to notice this problem.

A friend (the always perceptive Steve Atkins) pointed out that Yahoo had the same problem earlier this year. This makes the DMARC actions more understandable, if not necessarily more excusable. Crooks are using the stolen address books to send spam, and the DMARC policy stops a fair amount of it, which is good. Unfortunately, in the process of slamming the barn door after the horse left, AOL and Yahoo have crushed a lot of small animals on the way.

At this point, I channel Colin Powell's Pottery Barn Rule: You break it, you own it. It's their mess, due to their security breaches, so it's their responsibility to deal with the damage. All of their suggestions so far have the consistent theme that everyone one else spend their own time and money to change the way they work, and remove features their users depend on, to circumvent the DMARC damage. Yahoo estimates this affects 30,000 small mailers. Uh, no. Speaking as a mailing list operator, I'm willing, not eager, but willing, to work with the DMARC cartel to mitigate the damage, but they have to be willing to put some effort into it beyond waving their hands and telling us our mail volume is so tiny that we don't matter. (If that's the argument, the total traffic volume of all mail including the spam is a rounding error compared to video and P2P, so we should just shut all mail down, thereby solving the spam problem at a stroke. So let's not go there.)

In the next and I hope final installment, I'll suggest some short term and longer term ways that ISPs can use DMARC and preserve the mail services their users and everyone else counts on.

Written by John Levine, Author, Consultant & Speaker

Follow CircleID on Twitter

More under: Email

Categories: External commentary

Better Than Best Efforts Routing of Mission Critical Traffic and the FCC

CircleID - 10 hours 9 min ago

It appears that the FCC will permit exceptions to the standard, plain vanilla best efforts routing standard for Internet traffic, such as the paid peering arrangement recently negotiated between Comcast and Netflix. In both academic and applied papers I have supported this option, with several major conditions. See, e.g., Net Bias and the Treatment of 'Mission-Critical' Bits.

With no opposition that I have seen, companies like Akamai offer better than best efforts routing of "mission critical" traffic from content source to last mile, "retail" Internet Service Providers. This service improves the odds for congestion-free delivery of "mission critical" traffic, e.g., live video streaming. It appears that the FCC intends to permit better than best efforts routing options for retail ISPs.

I have no problem with ISPs throughout the Internet ecosystem providing different tiers of service, provided the upselling to higher QOS offers a true enhancement. Put more simply: better than best efforts should not foreclose the best efforts option, particularly for ventures and individuals whose traffic volumes have no possibility of causing congestion. Comcast and other retail ISPs should have the option of providing companies like Netflix with an insurance policy of sorts so long as all ventures and individuals do not have to follow suit. Without transparency and reporting requirements companies like Comcast can punish anyone refusing to upgrade from the old standard best efforts option by all but guaranteeing congestion and degraded service.

ISPs should have the opportunity to offer an enhanced deliver option with less latency, faster delivery speeds and improved odds for high quality of service. But the enhancement should not become necessary for any and all users.

Written by Rob Frieden, Pioneers Chair and Professor of Telecommunications and Law

Follow CircleID on Twitter

More under: Access Providers, Broadband, Net Neutrality, Policy & Regulation, Web

Categories: External commentary
Syndicate content
Licensed under Creative Commons Attribution Share-Alike 3.0 - Privacy policy Drupal theme by Kiwi Themes.