Slashdot Mirror
Domain Key Identified Mail vs Phishing
alphadogg writes "Some of the Internet's most powerful companies — including Yahoo, Google, PayPal and AOL — are brandishing a new weapon in the ongoing battle against e-mail fraud. DKIM is an emerging e-mail authentication standard developed by the IETF. DKIM, which stands for DomainKeys Identified Mail, allows an organization to cryptographically sign outgoing e-mail to verify that it sent the message. DKIM addresses one of the Internet's biggest threats: e-mail fraud. As much as 80% of e-mail that purports to be from leading brands, banks and ISPs is spoofed, according to a report released in late January by the Authentication and Online Trust Alliance (AOTA)."
Maybe those C_a_n_a_d_i_a_n Pharmacies selling V1a-gra can start using this technology so that I can finally know the stuff is ligit!
Seven Days with Ubuntu Unity
... until everybody starts using it! It might help, but all your friends and family won't use it so you cannot rely fully on this alone.
TFA advocates a
(*) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
( ) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
(*) It will stop spam for two weeks and then we'll be stuck with it
( ) Users of email will not put up with it
(*) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
(*) Requires immediate total cooperation from everybody at once
( ) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
( ) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
( ) Armies of worm riddled broadband-connected Windows boxes
(*) Eternal arms race involved in all filtering approaches
(*) Extreme profitability of spam
(*) Joe jobs and/or identity theft
(*) Technically illiterate users
(*) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
(*) CPU costs that are involved with cryptography
(*) Outlook
and the following philosophical objections may also apply:
( ) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
(*) Countermeasures must work if phased in gradually
( ) Sending email should be free
(*) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
(*) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your house down!
The majority of phishing and pharmacy mail coming to two accounts on my system are coming in with legitimate DKIM signatures... from Yahoo itself. With their CAPTCHA being broken several months ago (even if they only discovered it last month), the amount of "legitimate" Yahoo-domain mail with has been running at least 30 messages per day to one of those accounts.
So, where does that fancy new protocol standard thingy fit into this?
http://www.modernlifeisrubbish.co.uk/images/illustrations/how-viagra-spam-works-large.png
Another point: I read through the article. No mention of Microsoft?
How to Download YouTube Videos
...in the fight against spammers. I am all for it. Will this be the end-all-be-all tool? No, such a thing does not exist in the world of the inter-tubes, but if it can stop the majority of spoofing, then it is a good start.
Bearded Dragon
A site that I administer has a great introduction to DKIM for those interested:
http://what-is-what.com/what_is/domainkeys_identified_mail.html
(disclaimer: I am affiliated with that site)
It is dangerous to be right when the government is wrong.
The IETF refused to ratify SPF as an official standard because it didn't have Microsoft support.
Today, RFC 4408 is still an "experimental" protocol - due to Microsoft's hurt. Someone at Network World isn't familiar with the material they are reporting.
I think SPF addresses a real problem, and does it well; but, my MTA vendor doesn't want to spend the programmer cycles on something non-standard (they've been accused of being non-standard in the past, and don't want to risk the accusation again). I am annoyed that something so simple and easy as SPF isn't ubiquitous yet.
"The most sensible request of government we make is not, "Do something!" But "Quit it!"
I can see that this might help to reduce false positives (i.e. legitimate mail misclassified as spam), but I don't see how it can reduce false negatives (i.e. spam misclassified as legitimate mail). Basically it's similar to SPF but with cryptographic protection.
If the "big" spam targets (Paypal, Ebay and Amazon spring to mind) and the big mail providers (GMail, Hotmail, AOL etc) work together, it might reduce the amount of spam as well; for example, Paypal could state that *all* of their Mail will be signed with DomainKeys; Gmail could then immediately put all non-signed mail from Paypal into the spam folder (or reject it).
Since more and more people are using the big providers for their personal E-Mail, it might help with false positives there too.
It will not help with E-Mail from Domains not using DomainKeys, for domains set up by spammers (they can DomainKeys as everybody else) and for "small" domains, i.e. not deemed important enough by the big players to be listed as "non-spamming".
If the big players really work together on this, it might reduce spam a little but it will also damage the small players; since they're not whitelisted, their E-Mail is more likely to be classified as spam. Which makes the big players more attractive, so more people will use them and so on. It leads to a centralization of E-Mail.
I'm not sure whether this is good or bad.
Actually, I think they'll see this as a business opportunity. The risk here seems to me not that it will fail, but that it will succeed. That is, that people will start to only trust those big few who can afford to create such an identification mechanism. That will lead to the big ones reaffirming their "portal" role and making it harder for new entrants to achieve legitimacy. On a claim that new entrants are dangerous, it won't surprise me if (as with the network neutrality issue), the big ones jump in and say it's essential that they have special status. They like being special and competing among their (predictable) friends.
I like this technological proposal, btw. I just think it will, like all things, require some refinement before it's really working. But it sounds like a step forward. And at the same time something to be wary of ... in a calm way.
Kent M Pitman
Philosopher, Technologist, Writer
From: fraud-dept@interbankcorp.com
To: joe.smith@someplace.somewhere
Reply-To: fraud-dept.interbankcorp.com@freewebmailplace.bleh
Hello, we at InterBankCorp have been having a problem with other people accessing your account, and transferring funds out of it. We are working to rectify this problem, and all we need from you is your username, password, and pin number to confirm that you are the legitimate holder of the account.
You may note that this e-mail is not signed digitally, as we assured you all our communications with you would be. We are having problems with our e-mail servers, rest assured this message is legitimate as it contains our official logo. Our e-mail problems will be resolved shortly and we will go back to using digital signing to verify our authenticity with you.
Thank you again for helping us resolve this problem with your account.
The problem with DKIM is that it still relies on domain names. You can't spoof info@mybank.com, but you can by phisher.com, and have a valid DKIM signature for info@mybank.com.phisher.com, including links to https://mybank.com.phisher.com/ with no SSL certificate problems. You still need some other mechanism to verify that an email from your bank is from a domain that your bank owns, and this could be done easily by pre-sharing your bank's PGP key (for example). If banks want to stop their customers being caught by phishing attempts, they should include their PGP keys on CDs when they post out statements (or even just include the fingerprint on the paper statement and tell people how to check it the first time they get email), and tell people to disregard anything that's not sent by them.
I am TheRaven on Soylent News
TFA is about "phishing" which is slightly different from "spam" even though both use bulk email methods.
... while only increasing your legit email rejection count a slight bit. You are "winning" against spam. Or it appears that way.
The first problem with blocking "spam" is that there is so much of it (80%+ of all email is spam) that just about any stupid idea will result in a decrease in total spam received. Suppose you refuse to accept any email on odd-numbered dates. Since 80%+ of the email coming in was spam anyway, you've reduced your total spam message count
The second problem is that an approach that works for ONE sub-category will NOT work on a different sub-category.
Example, spam from Gmail is not stopped by greylisting even though greylisting is fairly effective at blocking spam zombies.
Will Domain Keys block spam? No.
Domain Keys will only help against a specific sub-category and only when configured correctly and verified correctly.
DKIM is a cheesy hack. If you want crypto use PGP or I guess S/MIME. You can not only sign but encrypt and do other proper things as well.
For eliminating phishing and other forged mail, I've found it far more useful to implement SPF on my MX host. Surely forged mail (where the policy says -all) is summarily bounced. Mail which passes an SPF check is let right through. Finally the rest is greylisted for 15min.
The big problem is that no one seems ready to commit to SPF. Most "big names" seem to say "?all" (neutral) or occasionally "~all" (soft-fail), making it impossible to definitively reject forgeries. More importantly, if they refuse to commit to what mail server they will use, they certainly won't commit to whether all mail will be signed.
DKIM fails because it signs the headers and not just the SMTP envelope. This breaks forwarding more than SPF does. Mailing list implementations and others seem to ignore the semantics of multiple signatures despite info in RFCs. And no one is going to re-open mail relays so it's extra complication over SPF which merely codifies existing behavior.
Lastly, this important point: Yahoo does not support DKIM. Despite sitting on the standard committee, they refuse to send DKIM headers or even parse DKIM headers on mail they receive. Rather they stick to DomainKeys which is broken in numerous ways (example: it doesn't specify which headers are signed so any headers added by intermediate relays cause signature failure). Yahoo doesn't play nice with others and hold up standards. Guess it's obvious why Microsoft is buying them, but they've sold out long ago. Yahoo's HTML used to be clean and nice; now it's garbage.
All of Yahoo's fascism and rudeness does nothing to help them. I get far more spam to my (unused) Yahoo mail account than I do to my (unused) GMail account. Yet Yahoo greylists mail for long times even when the sender is SPF, DKIM, and DomainKey signed. They don't share the greylisting among servers in their farm. That means even after the greylisting should be over it bounces yet again. Even when they "accept" mail it takes forever to show up. Somehow GMail which supports higher volumes, more usable interface, larger files, and I'm guessing more overall traffic blocks almost all spam, lets real mail through instantly.
Yahoo's time is over. Let's let them die quietly.
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
DKIM is designed to not require a root of trust for its certificates. Most DKIM installations simply use a free RSA private/public key pair generated using openssl. The private key goes on the SMTP server, and signs all the outgoing messages. The public key is placed on the DNS server servicing the domain. When a DKIM signed message is received, the receiving MTA retrieves the public key via DNS and verifies the signature.
If the signature verifies successfully, all you have proved is that the messages originated from the domain it claims to be from. This does not eliminate spam, since it is possible for iamaspammer.com to DKIM sign emails (DKIM is dead easy to implement), but it does go a long way to preventing a phisher from faking an email from ebay.com or whatever.
Life is like a web application. Sometime you need cookies just to get by.
I'd be very surprised if it was any less than 98% fake.
Je fume. Tu fumes. Nous fûmes!
The article has this so wrong that it's not even funny.
DKIM has pretty much nothing to do with phishing, and will do absolutely nothing to make phishing more difficult (though you could build some sorts of phish defenses based on DKIM I wouldn't bet on them being very effective, and they're certainly not what DKIM was really designed for).
DKIM is designed to allow the sender of a piece of email to cheaply embed a cryptographic signature in the mail to prove that they sent the mail. It's not usually used at the end-user level, rather a consumer ISP might sign all the mail coming from their smarthost or a company sending a newsletter may sign that email using their domain, even though they're sending it out via their ISP or via an ESP.
That signature doesn't mean anything other than I take responsibility for this email.
That has two uses that are (mildly) related to spam or phishing. The first is that it means that when you get a piece of email and hit the "this is spam" button it's easy for your ISP to work out who to send the feedback report to.
The second is a bit more subtle. It allows a sender of email to attach a persistent identity to the mail they send, in a way that can't be spoofed by others and which is independent of the IP address the mail comes from. That allows receiving ISPs to accurately track the reputation of senders of email, tied to that DKIM identity. If, say, Cisco signs all their newsletters with DKIM, and I as an ISP haven't seen customers complain about that DKIM signed mail from Cisco then when this new email arrives Cisco I can be pretty sure that my customers won't complain about that, either. I can avoid some expensive content based spam filtering, deliver the mail directly to the inbox and avoid false positives.
Note that I don't give that mail that red carpet treatment because it is DKIM signed - I do so because the DKIM signature proves that it comes from a sender that I've decided to trust because of their good behaviour in the past. You can think of it as kind of like a cryptographically signed "From" address, if you like, or as an identity that receivers can use to track reputation that's more convenient to receivers and senders than peer IP address.
Why not S/MIME or PGP? Well, DKIM can be cheaper to sign and check than either, but the real reason is that DKIM doesn't change the body of the email at all - just adds a few headers - so it doesn't require any special changes to the recipients mail client to be readable, and doesn't leave ugly detritus in non-DKIM aware clients. (The tradeoff of that is that DKIM is slightly fragile - some forms of body modification in transit will break the signature - but that's OK, as DKIM isn't designed to work 100% of the time, and if the signature breaks the mail will just be treated on it's merits, without the benefit of additional history).
DKIM will be (and is) used by spammers, of course, but it won't buy them anything other than making it easier for ISPs to track their reputations. And, in the case of spammers, that's a bad reputation (so they'll likely cycle through lots of identities in DKIM, just as they do everywhere else, to leave that bad reputation behind them). But it only provides advantages to the sender of the mail if they use a consistent DKIM identity over the long term, and consistently send mail recipients don't object to.
dkim.org has all the technical info and suchlike on DKIM.
SPF has some issues with Relaying. If your an org that sends out emails from a 3rd party from time to time, (IE, surveys, or other crap), then you will have issues with SPF. If I have site B send out email for me, claiming to be from my site, (site A) then it will fail SPF. (unless I add them to my DNS as a legitimate sender, which is a pain, and takes ahwile to propagate). If I use DKIM, I just need to pass them the key to use to sign the email. The emails will be signed, and will validate against my public keys. I've also heard about relaying problems in large companies, with decentralized email, ie, each divison or site has its own mail server.. this solves that.
What are we going to do tonight Brain?
I see a lot of confused posts about phishing and spam. Phishing is a subset of spam. I also find it funny how many skeptical/doom-and-gloom posts there are about Spam is impossible to stop. That is false. 100% false. It just requires a level of cooperation that is unlikely. It's not actually that bad right now, at least from the perspective of a mail server administrator. Or maybe I am just very lucky. Who knows?
DKIM is not a total solution against SPAM, so the snippy comments about the futility of filtering/fighting/etc aside, DKIM is only useful for signing the headers of an email BETWEEN mail servers. It was never intended as a solution to be run on the clients machine. As a mail administrator I fight Spam with several tools, DKIM only being one of them. I also don't give a damn what the client is running to stop spam either. That's not my business, but I think THAT is futility.
DKIM attempts to authenticate the content of an email. Failure means that the message was not sent by the certificate holder. That's it. So if DKIM is actually used, failures can be stopped before they are even delivered to the client. I am not an super genius when it comes to this stuff, but false negatives would have to be pretty low. It could only occur if the message was signed incorrectly, or there was corruption in the headers. False positives would involve breaking the encryption, taking over the domain, etc. Not an easy task to do, and if accomplished the domain owner has more to worry about it.
I sign the messages leaving my mail servers with DKIM. I also process them on the incoming. I don't outright reject any email based solely on DKIM. It just gets weighed in an overall decision about the message.
The other methods used:
SPF - DNS entries on the domains indicate the IP addresses that are authorized to send mail on the domains behalf. When implemented, this is quite powerful. VERY powerful in fact. The problem is that is not widely enough used at the moment and most domains will not enable policies that guarantee a failure if the IP address does not match. So once again, whatever I learn from SPF is weighted. Now if a message comes from a domain that ONLY allows email messages from specific IPs and the email message is not coming from that IP, the session gets terminated immediately. The email client does not receive the message at all.
No Relays - This one is really old and quite obvious at this point. I only accept mail for my users and nobody else's users.
Reverse DNS/PTR Lookup - I check the incoming connection and compare it's IP address against the one claimed in the headers. I perform Reverse DNS lookups and compare those values to the headers as well. This is where you get the domain to check with SPF in the first place.
Greylisting - I actually use this, but it can possibly cause problems. Once a mail server has sent a message the 2nd time, it gets added to the list and there is generally no problems from that point on. However, if a user is constantly clicking the Send/Receive button after registering on a new website, there could be some frustration.
SpamCop/Blacklisting - This is actually very effective. I lookup the IP address of every email and check it against these databases. A failure has its session terminated immediately. The vast majority of the entries in these databases are from infected computers sending spam. So if the owner of an infected computer sent an email message through via his mail server, it would not get rejected. If it was from his computer directly, it would. This represents over 90% of the spam my servers receive.
Whitelisting - This helps eliminate a whole lot of false positives. I don't have any global entries, but if the FROM address matches an address entry in the user's contacts found with the TO address, it will be let through.
Spam Traps - I have created some virtual machines were I get stupid for a good reason. I actually do my best to make sure that a bunch of email add
The IETF standard process runs by rough consensus. The IETF working group (MARID) that tried to standardize some of this stuff had everyone from Richard Stallman to Bill Gates trying to influence the outcome, along with a dozen proposals from "competing" technologies that would preferred no standard to theirs being excluded (this group included many folks who supported Domainkeys). SPF grabbed an early lead in deployment and mindshare by working outside the IETF, causing no great love with the IETF insiders.
It shouldn't be a big surprise that the MARID working group fail to reach consensus and was shut down without publishing any standards.
The folks involved with SPF (including me), and Microsoft both put forward their systems as "independent RFC submissions". These RFC submissions usually do not get put on the standard track and it could easily be argued that even being labeled "experimental" rather than "information" is a positive sign that the IETF sees at least some value in them.
By the time the DKIM working group was started, most of the hype had died away and a much smaller group of people were able to find consensus. DKIM was also backed by IETF insiders and most of the people from the SPF project that participated in the DKIM working group saw it as a complementary technology, rather than a competing one.
For email sent directly from one party to another, SPF, Sender ID, DomainKeys and DKIM all work very well.
In general, SPF (and Microsoft's Sender ID) has many more problems with email forwarders. There are ways around the problem using things like SRS or what gmail does and munges through the Received: headers to see which ones can be trusted and are forwarders. DKIM (and DomainKeys), on the other hand, rarely fail on forwarders, although it does happen when the forwarder adds trailers, do mime-rewriting, virus/worm scanning, etc.
In general, SPF has few problems with things like mailing lists. DKIM (and DomainKeys and Sender ID), on the otherhand frequently have problems with mailing lists.
Those of use that see SPF and DKIM/Domainkeys as complementary see domainkeys as very useful in identifying trustworthy forwarders which can then be used to make SPF more reliable, and SPF as a way of identifying trustworthy mailing lists, which can then be used to mail DKIM/DomainKeys more reliable.
SPF support for most open source mail servers can be found at libspf2.
You think the terminal behind the counter has a secure connection? One very large nameless bank that I can think of, uses plaintext over IP from behind the counter...
You are so far from correct, you're not even wrong.
S/MIME requires a certificate signed by a third-party certificate authority to be even remotely useful. DKIM does not. A self signed cert wouldn't work for S/MIME because any spammer could then just generate their own key pair and send.
PGP is an end-to-end signature and encryption solution. This is a completely different problem domain. PGP/GPG can guarantee that userA@placeA.com actually wrote the email to userB@placeB.com and that only userB@placeB.com could have written it.
BUT...
This requires that every single user on the internet gets a copy of PGP and shares their public key with everyone they know. Most businesses (even the legitimate ones) don't know all of the people that contact them. Could you imagine telling a sales department that they can only converse with people with people they have previously talked to? I'm sure they'd all quit long before you went bankrupt.
DKIM can work (and usually does work) at the organizational and domain levels. This is a huge win for adoptability since most folks haven't even heard of PGP let alone public key encryption let alone how to use them.
Your comment about SPF is almost correct, but the failure to widely commit to SPF is not because of apathy. After years of growing their IT infrastructure out, to list all possible SMTP launch points is not only prohibitively expensive, but hard to manage for very large organizations that span multiple subnets and multiple continents.
DKIM signs header fields, it's true, but organizations decide which fields are used for the signature. It's not like DKIM uses all fields. In fact, it can use the content of the email or a subset of the content as part of the signature as well.
Matching on the envelope is a *bad* idea. It was a bad idea for other technologies, and it'll be a bad idea for the next crop of technologies that use it. As soon as you have an email redirection from one relay to the other, the headers will usually remain intact but the envelope will most certainly change.
DKIM breaks on relay more than SPF? You are obviously high. DKIM was *designed* to be more relay friendly than SPF. If DKIM is causing you problems when going through relays, the problem lies with your DKIM setup, not with DKIM.
- I don't need to go outside, my CRT tan'll do me just fine.