Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Facebook The Internet Communications Crime Google Microsoft Security Technology

Big Internet Players Propose DMARC Anti-Phishing Protocol 92

Posted by timothy from the gotta-have-a-license dept.
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)."
This discussion has been archived. No new comments can be posted.

Big Internet Players Propose DMARC Anti-Phishing Protocol More

Big Internet Players Propose DMARC Anti-Phishing Protocol

Comments Filter:
  • no really what the down side to this? my paranoia is curious....

    • Re: (Score:1, Redundant)

      by Sloppy ( 14984 )

      The downside is that they're tying it to DNS, which is totally wrong. user1@example.com and user2@example.com are different identities. example.com can't, and shouldn't, be able to attest that something was said by user1.

      At most, example.com ought to be able to attest that an email came through their server. That's something, I'll admit, but decades behind the state of the art.

      • Except that DKIM isn't there to authenticate HUMANS but SERVERS. So the protocol does what it should, and solves it well (well... if you use DNSSEC, that is...). If you want to authenticate users, then use PGP.

    • Re: (Score:2)

      by gmuslera ( 3436 ) *

      Sending from not DKIM/SPF authenticated servers will be somewhat deprecated. Some uses (like mail forwarding) will become a bit more complex, and so the requirements for putting a "working" (by their definition) mail server on internet.

      Is not a "think on the children" (at least, not yet), but a "think on all those scammed people around". Some honest mails will become rejected, and some scamming will remain anyway.

      With all the multinational unilateral laws coming from US like NDAA, catching scammers/spamme

      • Sending from not DKIM/SPF authenticated servers will be somewhat deprecated.

        Wake up. IT IS already deprecated. Try for example to send a mail to Yahoo without using DKIM... It's been years it's like that by the way, and there for, it's been years I maintain the dkimproxy package in Debian for that reason...

  • Why a new protocol? (Score:3)

    by Hentes ( 2461350 ) on Monday January 30, 2012 @12:42PM (#38865953)

    What's wrong with PGP?

    • Re:Why a new protocol? (Score:5, Insightful)

      by rabbit994 ( 686936 ) on Monday January 30, 2012 @12:47PM (#38866017)

      Because average users have issues with it and they are people this proposal are trying to protect.

      If any security is going to happen for average user, it must be forced upon them. Otherwise, "it's too hard"

      • It also effectively breaks email if the other side doesn't have it installed, while great for internal communications, creates an administrative nightmare quickly and without fail. You need a real damn good reason to invest the IT cost in PGP, and some have it that use it. This one's not simple to force on the user, you have to understand domains, internet vs intranet, as well as the additional UI steps to begin. PGP is a poor implementation of something that should parallel ssl in it's usage, maybe the

      • Re: (Score:2)

        by Karzz1 ( 306015 )
        This appears to be transparent to the user. It is a layer that runs on top of SPF/DKIM which a user should not even be aware of.

    • Re:Why a new protocol? (Score:4, Insightful)

      by mlts ( 1038732 ) * on Monday January 30, 2012 @01:13PM (#38866343)

      PGP/gpg is ideal because it sits atop of everything else. However, most people wouldn't be bothered to generate and store securely a private key, much less build a usable WoT and making sure not just just absent-mindedly sign everyone's key that passes by.

    • A certain amount of "user effort" is required to use PGP -- at the very least, the user must obtain the public key of the person they are corresponding with, and they must then verify that the key actually belongs to that person, etc. Experience has shown that users are not willing to put in that level of effort, especially when most users do not really understand what their effort is accomplishing.

      Users' failure to understand what they are protecting themselves from when they use PGP is the biggest pro
      • Oh gods, this was something I went over, and over, and over with people when I worked tech support for an ISP, so many moons ago. People just don't get why the 'from' address isn't authoritative. I usually had to explain it like forging the return address on a physical envelope, then have them open Outlook Express, go to their mail account properties, and ask them what would happen if they changed the 'name' and 'email address' fields to something other than their own.

  • We already have email authentication (Score:5, Informative)

    by Sloppy ( 14984 ) on Monday January 30, 2012 @12:45PM (#38865987) Homepage Journal

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

    Everybody sign your emails, so that email from fuck-knows-who sticks out like a sore thumb. This would strike a great blow to phishing, and spam in general.

    And best of all, people don't need new software for it. You don't need a new standard because there are already two competing standards (PGP vs S/MIME) -- why add a third? Just start using what you've already got.

    • Re:We already have email authentication (Score:5, Insightful)

      by Nemilar ( 173603 ) on Monday January 30, 2012 @12:52PM (#38866091) Homepage

      The problem with PGP/signed-emails is that you're putting the burden on the user. I'm a pretty technical guy, and I don't even want to bother with it. There's no way that the average person it going to take the time to understand and implement PGP.

      The proposed solution puts the burden entirely on the system and the providers, so is more likely to be adopted and actually used (and therefore, successful in its end-purpose of stopping phishing attacks).

      • Re:We already have email authentication (Score:5, Interesting)

        by Albanach ( 527650 ) on Monday January 30, 2012 @01:12PM (#38866331) Homepage

        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.

        • Re: (Score:2)

          by Ihmhi ( 1206036 )

          Is there no easy tool that exists that will essentially do this for you? Why isn't there an application that automatically handles all of the PGP stuff on your computer so you don't even have to think about it?

      • Re: (Score:2)

        by mlts ( 1038732 ) *

        S/MIME is a compromise in this department. Signed E-mails will show that they are signed properly in Outlook, Thunderbird, and a number of web based E-mail readers.

        Of course, the ideal would be PGP/gpg validation of mails automatically because PGP wouldn't rely on CAs, as opposed to a WoT, but it would be better than nothing.

      • Re:We already have email authentication (Score:5, Interesting)

        by doublebackslash ( 702979 ) <doublebackslash@gmail.com> on Monday January 30, 2012 @01:38PM (#38866587)

        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.

        • Re: (Score:1)

          by Anonymous Coward

          So, basically, you want an asymmetric algorithm for signing where your provider would store your private key.
          Then, to authentify an email, your client would ask the announced server of your contact for the public key.
          The server can be authentified by its certificate and the transaction would be secure over ssl.
          This way, it would be transparente to the user because all the asymmetric complex part is done by your provider and you trust him thanks to its certificate.

          But, wait a minute, remind me what is in the

        • Re: (Score:1)

          by tokul ( 682258 )

          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!

          Existing protocols are about getting or sending emails. They have nothing about feeding custom settings to client. You also missed two major part of signing emails. User must know private key password and private key must be private as in "available

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

        How? All these clowns want is for the user to be able to recognize the bank. The bank recognizes the user by password, so as long as the user isn't giving out the password to phishers, the account is secure. The only "hard" part of using GPG with email is maintaining your own identity, but here it's not needed. They just have to make their clients display S/MIME and PGP/MIME and then distribute in a secure way a list of public keys of all their buddies.

        But companies like Microsoft want a lot more pie than

      • Re: (Score:2)

        by Magada ( 741361 )

        Key management is more of a bitch than it needs be, for sure.

        Frankly, I'd rather rely on OpenID providers to authenticate sent e-mails somehow. Nonces, probably.

        Oh, I claim prior art on this idea, by the way...

    • I used PGP to sign my emails. I stopped because too many people were pissing and whining about "all the extra crap" in my emails and they didn't know what it was for and dammit will you just stop it you're confusing my little brain. Granted, that was a couple of years ago so I don't know if mail clients have gotten smarter about presenting the messages without the PGP signing info (but you can damn well guarantee they know how to render HTML in the client).

    • Re:We already have email authentication (Score:5, Interesting)

      by heypete ( 60671 ) <pete@heypete.com> on Monday January 30, 2012 @01:30PM (#38866489) Homepage

      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.

    • While I realize this is more of an implementation issue than a conceptual issue, the reason why people aren't signing their emails is how clients make the signed emails stand out. I had a coworker who had digitally signed emails, and Outlook showed a little red ribbon next to the message. I'm sure the idea being that it was letting me know that the message was digitally signed. Did I know for %100 that the email was from this person? No. Perhaps someone had his credentials and was using his system in a mali
      • The question would more be: did you manually check the fingerprint he gave you on a paper, before sending you signed emails, when you thought that receiving signed emails was safer? If you didn't, then it was as good as if they were not signed.
        • I didn't think that signed emails were safer. That was kind of the point of my comment. Due to the overwhelming percentage of unsigned emails I've received, who have been from the sender, I nearly always believe that an email actually came from the supposed sender. Someone can sign their emails one day, and not on another and it's hardly noticeable. A proper warning system would be one where the clients notice a slight aberration from the norm, not something which relies on humans to notice that signatures
    • Even on cryptography mailing lists and newsgroups most people are not signing their messages. Getting people to put in the effort needed to set up PGP is just not going to happen; it needs to be the default, and it needs to be easier. I say this as someone who has been signing his emails for years, and who has tried for years to get other people to do the same.

      Here is how the conversation usually goes, assuming that you get as far as convincing them that signing is something worth the time to do:

      Cry

    • Re:We already have email authentication (Score:4, Interesting)

      by IamTheRealMike ( 537420 ) on Monday January 30, 2012 @02:03PM (#38866857)

      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 info@paypal.com or sloppy@gmail.com, 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 "campaign@foo.com", 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

      • 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.

        Note only that. With DKIM, when you receive a mail, basically, its header are telling that the mail is signed, and that you can go ahead and check the DNS for the key. But if there's no such thing in the email, then no further check will be made. With DMARC, you will finally have a way to tell if a domain requires DKIM or SPF checks, which wasn't in the specs before.

        some random guerilla marketing team contracted a third party provider and told them to send as "campaign@foo.com", even though it's not being sent via foo.coms servers

        DMARC will force M. marketing to send his emails correctly, because now it's going to be really impossible to send emails without the foo.fr se

    • As an experiment (and desire to use it) I tried signing my emails, but I got a LOT of complaints from people using Microsoft Outlook etc. What MS email package did was just append the text code of the signature to the email, making it look very long, and full of nonsense text. Other packages understood what to do and just displayed the email as normal, with a padlock which you could click to read the signature.

      I haven't used a signature since as too many use Microsoft Outlook... although maybe it has been f

      • After 20 years of PGP existence, we still get this stupid answer that it's the fault of Microsoft? Come on! Move on, that excuse is not acceptable anymore. If you have stupid contacts that don't understand, either send then a link to wikipedia (I'm sure it explains well what PGP does and how to use it), or just ignore the complains, for the benefits of all the others who aren't using retarded software!
    • This is totally irrelevant to the topic of DMARC. Here, we're talking about authenticating SERVERS, not HUMANS, to make sure that you aren't receiving spam from any random robot, part of any random botnet / hacked servers. Plus there's all sorts of reason why you don't want to receive only PGP signed emails, one of them is that you still want to receive emails from people you don't know, in which case they wont be authenticated (because you *DO* manually check the fingerprint of the PGP public key you downl
  • Someone used to post a form with few boxes checked saying stuff like, "your idea will not work because: [x] blah [*] yadda yadda yadda", everytime there was an idea to combat spam/phish. Wonder what happened to him.

  • You're proposing (Score:5, Funny)

    by guruevi ( 827432 ) on Monday January 30, 2012 @01:06PM (#38866277)

    Your post advocates a

    (x) technical ( ) legislative (x) 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
    (x) 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
    (x) Requires immediate total cooperation from everybody at once
    (x) 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
    (x) Lack of centrally controlling authority for email
    ( ) Open relays in foreign countries
    ( ) Ease of searching tiny alphanumeric address space of all email addresses
    (x) Asshats
    ( ) Jurisdictional problems
    ( ) Unpopularity of weird new taxes
    ( ) Public reluctance to accept weird new forms of money
    (x) Huge existing software investment in SMTP
    ( ) Susceptibility of protocols other than SMTP to attack
    ( ) Willingness of users to install OS patches received by email
    (x) Armies of worm riddled broadband-connected Windows boxes
    ( ) Eternal arms race involved in all filtering approaches
    ( ) Extreme profitability of spam
    (x) Joe jobs and/or identity theft
    ( ) Technically illiterate politicians
    (x) Extreme stupidity on the part of people who do business with spammers
    (x) Dishonesty on the part of spammers themselves
    ( ) Bandwidth costs that are unaffected by client filtering
    ( ) Outlook

    and the following philosophical objections may also apply:

    (x) 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
    (x) Countermeasures must work if phased in gradually
    ( ) Sending email should be free
    (x) Why should we have to trust you and your servers?
    (x) 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.
    (x) 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!

  • Still have to fight layers of stupidity (Score:5, Interesting)

    by sootman ( 158191 ) on Monday January 30, 2012 @01:16PM (#38866373) Homepage Journal

    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.

  • Yeah... (Score:3)

    by 3vi1 ( 544505 ) on Monday January 30, 2012 @01:29PM (#38866485) Homepage Journal

    "Spam will be a thing of the past in two years' time."

  • Did anyone else read that acronym as DARMOK at first glance? I keep picturing Picard getting Data to filter the spam in his inbox...

    • Re: (Score:2)

      by armanox ( 826486 )

      I think that spam is sovled by the 24th Century. That, and it looks like email is out too.

  • Seriously, if all the major free e-mail services signed every outgoing e-mail, wouldn't that cover about %MADEUPPERCENTAGE (but certainly more than half, perhaps closer to 90%) of all e-mail? Have Gmail/Yahoo/Hotmail/whathaveyew create a public/private key for each user, create a new e-mail header for keys (so it's not lurking in the sig confusing people.) This covers most of the Joe User situations (people who run their own server would know enough to sign their own email) and puts the onus on Hotmail/Gma
    • Seriously, what you are asking for above is DKIM, since there would be no point into having a different signature for each users if they aren't the only one holding the private key... With DNSSEC, you wouldn't need Gmail/Yahoo/Hotmail/whathaveyew to have their key signed, but just a record like this:

      $origin _domainkey.example.com.
      postfix TXT "k=rsa\;p=an-rsa-key-that-slashdot-dont-let-me-post"

      would simply be trust-able. So, DKIM + DMARC + DNSSEC == authenticated From: domain. If you need the user@ part

  • um... (Score:2, Interesting)

    by Charliemopps ( 1157495 )
    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.
  • If you want a certified email then set up an electronic postal service and give the new certified domain to them. To send a certified email an account would need to be set up with them and your information verified before you are permitted to send anything through them. The domain would have a set range of IP addresses certified and when a recipient receives a an email from Bank of America if it isn't from BofA@USEPO.gov AND an IP in the white-listed range then delete it. The service would need to charge a
  • The weak link in any security scheme is the humans that are involved. I don't see how DMARC, DKIM, SPF or any other combination of policies and technology is going to prevent the compromise of the human elements. Phishing is *way* too lucrative an enterprise to be abandoned; the phishers and the criminal organizations that back them are not going to give it up without a fight. What is going to stop a criminal organization, for example, from suborning the system administrators at a DMARC-compliant hosting

  • About a year ago, when I was trying to figure out why notices from BofA were crashing my Moto RAZR, I did a little reading up on DKIM, and found it rather interesting. What I found even more interesting is that all the DKIM support I could locate operated at the MTA level (sendmail, postfix, etc.). I couldn't find any client-side tools that would verify DKIM signatures.

    Has this situation changed (or did I miss something)? Are there any tools I could plug in to, say, 'mutt' to verify DKIM signatures?

    Sc

Slashdot Top Deals

BLISS is ignorance.

Close