Big Internet Players Propose DMARC Anti-Phishing Protocol

judgecorp writes "Google, Microsoft, PayPal, Facebook and others have proposed DMARC, or Domain-based Message Authentication, Reporting and Conformance, an email authentication protocol to combat phishing attacks. Authentication has been proposed before; this group of big names might get it adopted." Adds reader Trailrunner7, "The specification is the product of a collaboration among the large email receivers such as AOL, Gmail, Yahoo Mail and Hotmail, and major email senders such as Facebook, Bank of America and others, all of whom have a vested interest in either knowing which emails are legitimate or being able to prove that their messages are authentic. The DMARC specification is meant to be a policy layer that works in conjunction with existing mail authentication systems such as DKIM (DomainKeys Identified Mail) and SPF (Sender Policy Framework)."

Re:We already have email authentication

[Albanach]

There are also issues with PGP and webmail used by probably the majority of home users, as well as the multitude of devices people now have for email.

You need to sync keys between devices securely, and with webmail you pretty much need to have a browser plugin take over the signing part, unless you want to entrust your private key to a third party.

Simply checking mail onan untrusted web terminal then becomes problematic - sure you can read signed but not encrypted email, but if you tell people it's okay to trust that sometimes, they won't bother checking at other times.

Still have to fight layers of stupidity

[sootman]

Random fun fact: Yahoo uses something domain keys to authenticate their email. I can send myself a short message (like, just a URL) and it winds up in my spam folder.

Re:We already have email authentication

[heypete]

I'm an American studying in Switzerland. I bank with PostFinance, the post office-run financial institution.

Any electronic documents or messages from the bank are digitally signed: PDFs are signed and time-stamped using the built-in PDF signature methods. Emails, even the general informative newsletter containing no account-related information at all, are signed with S/MIME. Any account related communications take place using the internal messaging system on their secure website (which requires the user have access to their bank-issued smartcard and offline calculator-like challenge-response device). The instructions that came with the bank card and calculator device make it very clear how to verify that one is actually on the bank's website.

It's trivial to verify that documents and emails are actually issued by the bank, and the login method for the bank's website makes phishing much more difficult.

Compared to USAA, one of the more clueful US banks, this is excellent. Emails from USAA have the last four digits of the account number in the top-right of the message so as to "authenticate" that the message came from the bank. Of course, this is trivial to reproduce and offers no real validation. It's a shame, really.

If more banks (and indeed, more senders in general) signed their messages, that'd be a major improvement. If the big webmail providers (Gmail, Yahoo, and Hotmail) verified S/MIME signatures and displayed a suitable indicator to users, that'd be even better.

Re:We already have email authentication

[doublebackslash]

The problem with PGP/signed-emails is that you're putting the burden on the user.

Okay, I'll bite. (not TOO hard, mind)

So lets use PGP and still put the burden on the ISP / email provider / Facebook / anyone but the user

1. Every email client in the world ships with PGP support
2. Every email provider issues a key to their users. This can be done by the email client getting the key from the server when it authenticates (say a specially crafted email that it then hides from the user. No need to make it complex like extending the protocol! Just use existing technologies like "Magic emails") And emails of this format could be filtered trivially from being recieved (so no emailing someone a new private key!)
3. Every email is signed and verified and those that aren't are flagged as "DANGER DANGER!" or ones signed but from somewhere not trusted, etc etc. PGP has a wonderful system of trust built in. It can be used in any way they want (google, MS, Yahoo, etc publish public keys and sign user keys with it, etc)

Lastly if someone savvy enough wants to use their own PGP key they can. Just get it signed by their email provider or some other such proof that they control that email address. PGP has this sort of thign already, very nice! https://keyserver.pgp.com/ [pgp.com]

Bonus points to PGP: since it already has the idea of a web of trust it can be used to GREAT effect. The email client could regognize that you seem to work with this person or email them a lot and ask, "Do you know this person in real life? Do you trust that this email is from them?" and sign keys that way. In this way one could have direct evidence that an email comes from someone that they can trust rather than just Google's big red rubber stamp. How novel!

We could really make this work with popular social media sites like facebook (I'm not a member, but lotsa people are) and show where this person is on your social graph (if they are at all)

So that is how we can use PGP, have it be as good AND BETTER than something new and not make the users do it. Sure there are more than a few flaws in the above but that is the basic outline.

um...

[Charliemopps]

Is it just me or doesn't the majority of the spam I get come from: AOL, Gmail, Yahoo Mail and Hotmail, and major email senders such as Facebook, Bank of America.

To me, this just seems like an attempt by big spammers to eliminate little spammers.

Re:We already have email authentication

[IamTheRealMike]

Sign your emails. The tech has been out there for two decades. Decades, and that's real world time, not "internet time."

You're way behind the times. Go read up on email authentication and DKIM. You will find that a significant fraction of all email on the internet is being signed automatically - that is how DKIM works. The difference is, it's signed with the email providers keys instead of the users keys. But this is good enough to stop phishing because if an email claims to be from [e-mail] or [e-mail], the signature proves it came from PayPal or Gmail and you can then trust that they won't sign such mail unless it really did come from that address.

DMARC solves a problem that real world DKIM deployments have - merely signing your mail is not enough. You need to tell people what to do if signature checks fail. And you need a way to learn about failing signature checks, because large organizations often have incredibly complex mail streams, including mail they know nothing about because some random guerilla marketing team contracted a third party provider and told them to send as "[e-mail]", even though it's not being sent via foo.coms servers. This has made real deployments of DKIM quite tricky and ad-hoc affairs. DMARC will standardize this and make deployment feasible even for smaller organizations.

DKIM has other problems, like the number of mail relays that think it's OK to modify mail in transit whilst claiming it comes from the original sender, but those are all issues you get with retrofitting digital signatures onto an existing infrastructure./p