RE: UCE - a simpler approach using just digital signing?
On Saturday, January 31, 2009 6:36 AM, Sascha Silbe wrote: Another scheme (that could be combined with the above one to solve only the CC party problem) would be accepting only PGP mail and use a manually updated whitelist / web of trust of PGP keys. Unfortunately, PGP still isn't widespread enough to reject non-PGP mails and the ones not using it are often far more susceptible to address harvesting malware, limiting the usefulness of such a filter. On Saturday, January 31, 2009 2:56 PM, John Levin wrote: This has the same fundamental problem as Zoemail and any other white list system. It's really easy to implement a white list. Unless your name is Paypal, the amount of mail forging your address is vanishingly small, and the utterly insecure From: line address works just fine for practical purposes. I use that to manage my 12 year old daughter's mail. On Saturday, January 30, 2009 6:17 PM, John Levin wrote: This is the wrong place to go into detail about its limitations, although it should be self-evident that if it were effective, sometime in the past 13 years we'd have started using it. Though John's January 30th note was about Zoemail, I am reacting to the words PGP still isn't widespread in Sascha's post about PGP. I also was once under the assumption that I should always have PGP installed. I was able to verify signatures, and I thought that one day, most people would gravitate to PGP in some form. However, losing a fight with PGP Support over whether the enterprise plug-ins I was requesting for a corporation would reduce the security level of their product (long story about trying to integrate it with single sign on), and also spending many hours over three months trying to install the commercial version on Vista, only to have the PGP engineers tell me that I would have to uninstall all my other Outlook plug-ins for them to continue working on the problem (e.g. card scanner), I realize that it will never be the solution of choice for either commercial enterprise or home office given its current support model. I have not used it since July and have not missed it a bit. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: UCE - a simpler approach using just digital signing?
One idea I have not seen mentioned here (and which I have not yet encountered in RL, but only weird people send me email these days) is for the sending MTA to use pgp to encrypt mail using the recipient's public key, available on one of the key servers near you. I don't understand what problem this is intended to solve. Bad guys can look up PGP keys just like good guys, so all this would accomplish would be to fill your inbox with signed spam. Perhaps it would be useful to make a section of the ASRG wiki in which we describe the difference between the spam problem and the other problems that people confuse with the spam problem, such as the introduction problem and (more familiar to cryptographers) the authentication problem, the interception problem, the non-repudiation problem, and doubtless others that I can't think of just now. R's, John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: UCE - a simpler approach using just digital signing?
On Fri, Jan 30, 2009 at 01:47:23PM -0800, Ray Dillinger wrote: Each time Fred gives out his email address to a new sender, he creates a trust token for that sender. They must use it when they send him mail. That's basically what I'm using, just without the digital signature part: each person/organisation/website/whatever gets a different email address for communicating with me (qmail makes this easy to implement); mailing list and bugtracker addresses are filtered to accept only mail with the correct headers. It works much better than content filters, but it's basically limited to 1:1 communication (with a mailing list looking like a single entity as it forwards traffic both ways). Most importantly, it breaks for CC parties (*). Address lists on paper given out to a large number of participants are problematic as well (those utilizing paper lists are mostly non-tech-savvy - thus prone to attacks - and changing the address is hard due to the long update interval of the list). To get on-topic again: Another scheme (that could be combined with the above one to solve only the CC party problem) would be accepting only PGP mail and use a manually updated whitelist / web of trust of PGP keys. Unfortunately, PGP still isn't widespread enough to reject non-PGP mails and the ones not using it are often far more susceptible to address harvesting malware, limiting the usefulness of such a filter. (*) CC party: group discussion without predetermined participants (so no mailing list could be set up in advance) CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature
Re: UCE - a simpler approach using just digital signing?
That's basically what I'm using, just without the digital signature part: each person/organisation/website/whatever gets a different email address for communicating with me (qmail makes this easy to implement) I do that too -- I bet half the people on this list do, and there's lots of free and commercial services like Yahoo and Spamex who will let you do it. But it's not much of a solution to spam because it requires significant manual work to maintain the addresses, and only deals with places where you individually give them the address to send mail to. Another scheme (that could be combined with the above one to solve only the CC party problem) would be accepting only PGP mail and use a manually updated white list This has the same fundamental problem as Zoemail and any other white list system. It's really easy to implement a white list. Unless your name is Paypal, the amount of mail forging your address is vanishingly small, and the utterly insecure From: line address works just fine for practical purposes. I use that to manage my 12 year old daughter's mail. But whitelists replace the spam problem with the equally intractable introduction problem, deciding whether to accept the first message from someone you don't know. People have been thinking about that for a long time (indeed, for millenia in contexts other than e-mail) and the snarky comments I made yesterday about wonderful anti-spam ideas apply here, too. The ASRG is still eager to hear from people who want to do just about anything related to spam other than hash over known-ineffective old ideas. See http://wiki.asrg.sp.am. R's, John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
UCE - a simpler approach using just digital signing?
I have a disgustingly simple proposal. It seems to me that one of the primary reasons why UCE-limiting systems fail is the astonishing complexity of having a trust infrastructure maintained by trusted third parties or shared by more than one user. Indeed, trusted third party and trust shared by multiple users may be oxymorons here. Trust, by nature, is not really knowable by any third party, not the same for any set of more than one user, and in fact the people most willing to pay for it at least where UCE is concerned, experience shows to be usually the _least_ trustworthy parties. So why hasn't anybody tried direct implementation of user- managed digital signatures yet? A key list maintained by individual recipients for themselves alone could be astonishingly simpler in practice, probably to the point of actually being practical. In fact, it is _necessary_ to eliminate third parties and shared infrastructure almost entirely in order to allow mail recipients to have the kind of fine-grained control that they actually need to address the problem by creating social and business feedback loops that promote good security. As matters stand today, there is no protection from UCE. If I know there is a user account named 'fred' on the host 'example.com', then I have an email address and I can send all the UCE I want. And poor fred has the same email address he gives everybody, so he gets spam from people who've gotten his address and he has no idea where they got it. All his legitimate correspondents are using the same email address, so he can't abandon it without abandoning *all* of them, and he doesn't know which of them gave his address to the spammers. What if email accounts weren't that simple? Consider the implications of a third field, or trust token, which works like a password to fred's mail box. Your mailer's copy of fred's email address would look like fred#to...@example.com where token was a field that was your own personal password to fred's mailbox. Your system would still send mail to f...@example.com but it would include a Trust: header based on the token. The simplest solution I can think of would be a direct application of digital signatures; the trust token would be (used as) a cryptographic key, and the headers of any message would have to include a Trust field containing a digital signature (a keyed cryptographic hash of the message, generated by that key). Messages to multiple recipients would need to contain one Trust field per recipient. Its use would follow simple rules: Each time Fred gives out his email address to a new sender, he creates a trust token for that sender. They must use it when they send him mail. So fred gives his bank a key when he gives them his email address. If fred were willing to recieve mail from strangers, he could publish a trust token on his webpage or on usenet or whatever - it would be painless to revoke it later, so why not? If fred trusted someone to give out his email address, he could give that person multiple trust tokens to pass along to others. Again, an error in judgement would be painless to revoke later. Fred can revoke any trust token from his system at any time, and does so whenever he gets spam with a trust token he issued. In UI terms there'd be a button in his mail reader that works as, this message is spam, so revoke this trust token because now a spammer has it. Other messages sent with the same trust token would disappear from his mailbox instantly. Fred might not push this button every time, but at least he'd know what spam he was getting due to (say) his published trust token on his webpage or usenet, and what spam he was getting due to his relationship with a bank, and he'd have the option of turning any source of spam off instantly. In the short run the .aliases file on the mail host would need a line so it would know to deliver mail to fred#anyth...@example.com to fred. This is not because a legitimate email would ever include the literal key, but for purposes of alerting fred's MUA to protocol breaches, so it could do key management. Fred's MUA could then be upgraded to use tokens without affecting other users on the system.In later MDA's that handle trust tokens directly, this forwarding would be automatic. Whenever Fred gets email sent by someone using a trust token, his system tells him which token - ie, what sender he gave that trust token to. So email sent to fred using the trust token he gave his bank will show up in his mailbox under a heading that says this was sent by someone using the trust token you gave your bank. Whenever fred gets email for fred#to...@example.com and that's still a legitimate token, his system revokes the token, sends him an automatic note that says which trust token was revoked, and bounces the email with a message that says, Your mailer is not using trust tokens. Your mail has not been
Re: UCE - a simpler approach using just digital signing?
On Jan 30, 2009, at 4:47 PM, Ray Dillinger wrote: I have a disgustingly simple proposal. [Basically, always include a cryptographic token when you send mail; always require it when you receive mail.] There is little effective difference between this an whitelists. If I only accept mail from people on my whitelist, spammers can only send me mail through three modes of failure: 1. They randomly pick a return address that happens to match someone on my whitelist. I think we can agree that this is rare enough that it isn't worth worrying about. 2. A spammer somehow finds pairs of people S and R, where S sends to R, and fakes S as the sender for spam directed to R. This would be a new mode of attack - spammers today just spurt out millions of messages based on very little information. Sure, someone *could* start this kind of attack - but it's difficult to get the necessary information to mount it, and it seems unlikely that it would make economic sense to spammers, who can live with tiny response rates because they can so cheaply generate targets. 3. This is a variant of (2) that actually does occur today: The spammer takes over S's machine and sends to the same people S sends to. Viruses try to spread by this mechanism; they often succeed. In principle, a spammer could write a virus that simply sent the (S,R) information from the infected machine, though I don't know that they've ever bothered. Either a type 3 attack, or a type 2 attack where the information comes from invading S's, machine, can of course just as easily grab all the tokens on S's machine. The solution proposed is that this will be noticed quickly, and the tokens will be marked as no longer valid. But that's really no different from R simply removing S from his whitelist. Really, cryptography is a non-issue here. As long as S and R share some information - even S's address will do - that R can use to filter messages; and there is no cheap way to get large amounts of (S,R)-pair information; that information can be the key to a whitelist. (Some mailing lists do this: E.g., if you want to post to RISKS, you're asked to include the string notsp at the beginning or end of the subject line. This is public information, so a spammer could easily do this *if he chose to specifically target the RISKS mailing list*; but there's no way he can do this automatically on a mass scale. An individual could easily reach a similar agreement with anyone sending him mail. Of course, the downside is that you can now *only* receive mail from those on your (logical) whitelist. That's fine in some cases, unacceptable in others. You can semi- automatically grow your whitelist by sending using some kind of challenge/response. For example, if you could send back the message with a note saying: You're not on my whitelist, if you want to reach me resend this message with 'xyzzy' in the subject line. Spammers don't bother to look for such messages right now (though if you made this automatic enough, and enough people adopted it, they would have a reason to!) so they won't be able to sneak on your whitelist that way. However, many people writing to you won't want to be bothered - and automated mailings that you *do* want to receive and don't know the details of ahead of time (e.g., approval messages for mailing list requests you make) won't get through either. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: UCE - a simpler approach using just digital signing?
Hi. One of the hats I wear is the chair of the Anti-Spam Research Group of the Internet Research Task Force, which is down the virtual hall from the IETF. You know how you all feel when someone shows up with his super duper new unbreakable crypto scheme? Well, that's kind of how I feel here. Dealing with spam is surprisingly subtle, a lot of smart people have been thinking about it for a long time, and most new ideas turn out to be old ideas with well known flaws or limitations. Consider the implications of a third field, or trust token, which works like a password to fred's mail box. Your mailer's copy of fred's email address would look like fred#to...@example.com where token was a field that was your own personal password to fred's mailbox. It's not a bad idea. Its best known implementation was done in 1996 by Robert Hall of ATT Labs who called it Zoemail. You can learn all about it in US Patent 5,930,479. This is the wrong place to go into detail about its limitations, although it should be self-evident that if it were effective, sometime in the past 13 years we'd have started using it. You're all welcome in the ASRG, which has a wiki at http://wiki.asrg.sp.am with pointers to the mailing list and other resources. One of our slow moving projects is a taxonomy of anti-spam techniques, both ones that work and ones that don't work. If you'd like to contribute, drop me a note and I'll give you a password so you can edit it. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor More Wiener schnitzel, please, said Tom, revealingly. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: UCE - a simpler approach using just digital signing?
On Fri, Jan 30, 2009 at 1:47 PM, Ray Dillinger b...@sonic.net wrote: This is basic digital signatures; it would work. What's your transition plan? How do you deal with stolen trust tokens? (Think trojans/worms.) Also see: http://craphound.com/spamsolutions.txt -- Taral tar...@gmail.com Please let me know if there's any further trouble I can give you. -- Unknown - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
