Folks, I think this thread has deviated enough from its original intent that the best place to continue it is on the ASRG list -- there's no point in bothering the entire IETF with yet another anti-spam discussion.
S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, 25 February, 2004 04:50 Subject: digital signature request > this is a request for this list to be digitally > signed by the list processor. > > to all list members. if after reading this post > you would like the list processor to digitally > sign all posts please say so (and tell the list > owner) so that the level of interest can be > gauged. thanks. > > i'm making this request because i need a way to > positively id the messages from this list. i'm > spending way too much of my time culling spam from > my real email even though i'm employing the latest > spam filtering tools. please give me the one > simple tool i know of that will allow me to > positively differentiate the mail from this list > from all others - a digital signature. > > signing all list messages won't be detrimental to > list recipients not interested. it will however > allow folks wishing to implement anti-spam > measures around digital signatures to do so. > mailing lists often require that recipients > confirm their email address as an anti-spam > measure for the list. please help list recipients > implement their own anti-spam measures by allowing > the list messages to be positively identified. > > to be clear, this is a limited scope spam > solution, but it works. and it will continue to > work provided the underlying cryptography is sound > (unlike many other anti-spam technologies that are > simply clever hacks in an escalating spam/anti- > spam arms race). > > some folks say that there will be no spam solution > as long as email is free. i say there will be no > spam solution as long as you expect anyone to be > able to send email to you without first proving > they are not a spammer. > > part of finding a solution is to revision what > email is. i argue that email can no longer be a > method of unfettered *initial* contact. once that > is accepted then this solution doesn't seem > painful. i suspect that there won't be a solution > until email is seen from this perspective. as > noted above, mailing lists are essentially > adopting this perspective (to better manage spam > on the list side), it would be helpful if they > took an additional small step that would enable > list recipients to better manage spam on their end > too. > > there's no need for a larger web of trust other > than one that is personally maintained when using > digital signatures to defend against the onslaught > of spam. your personal web of trust (a.k.a. your > keyring) is your unspoofable anti-spam whitelist. > this is where the revisioning of email occurs. > instead of email being the way you initially make > contact with an entity, with digital signatures it > can serve as a reliable communications channel > *once* contact has been established. > > my intention is to implement a procmail recipe at > the mail server level. the procmail recipe will > be used to check incoming mail for whitelisted > digital signatures that have been uploaded from > each individual user. > > mailing lists could use the same recipe, no > messages would be handed over to the listserv > software unless it was signed by a whitelisted > signature. again, this won't stop machines from > being compromised but as soon as a machine is > compromised that entity will be *immediately* > notified by their peers. in the case of a mailing > list *many* people will suddenly know who's > compromised and the list can even have a mechanism > that allows a whitelisted key to be removed once > it becomes compromised. this would also serve the > dual function of indirectly alerting the owner of > the compromised host since they will investigate > why they are no longer receiving list traffic. > > regarding whether to utilize inline or mime GPG, i > say use either. the preferred solution will self- > select over time. it is possible to create a > procmail recipe that can handle both methods. > > Two key benefits of this anti-spam technology: > > 1. it works and will likely continue to work > beyond the foreseeable future > > 2. it can be implemented without the consensus, > from the bottom up > > below are my responses to posts in a few mailing > list threads regarding digital signatures and > spam. please read my responses as they will > likely answer many of the questions that may > result from reading what i wrote above. apologies > to the folks whose comments i'm replying to for > not referencing their names (i didn't have the > time). > > looking forward to feedback. > > ciao, > > david > -- > spam is something we can eliminate by > changing our personal behaviors and expectations > and cooperating. and it can happen gradually. > > > > thread: ietf - proposal for built-in spam burden > & email privacy protection ----- > > >>2. Except for senders in a whitelist (e.g., > >>list mail), I bounce to the sender any email > >>that is NOT encrypted with my public-key, > >>providing my public-key and instructions for the > >>sender to resubmit the message properly > >>encrypted. > > > >Anything at all that generates a bounce message > >on a mass-produced mailing acts as a "damage > >amplifier" from the basic internet backbone's > >point of view -- at least doubling the associated > >automated traffic and wasted/misused resources. > >These days such a bounce is especially fruitless, > >as all viruses and quite a lot of SPAM have forged > >headers that the stupid bounce agents cannot or do > >not parse. > > > >This is pet peeve of mine as it is -- I got (and > >continue to get) more bounce messages from mydoom > >reporting that mail "from me" is contaminated than > >I do copies of the virus itself. No virus for two > >years now hasn't forged mail headers -- the From > >field is totally irrelevant in all current viruses- > >- yet all the AV programs in the world think they > >are doing you a favor. NOT. > > > >Now imagine that sort of stupidity scaled out so > >that every MTA in the world is checking esigs and > >bouncing improperly signed mail. Imagine the > >loops created when a legacy mailer or improperly > >configured mailer bounces the bounce messages back > >to the bouncer, to be bounced again. Nightmarish. > > solution - don't auto-respond, give out a keyword > with your email address, this will allow initial > contact to be more easily plucked from the sea of > spam - in the long run as more people digitally > sign email spam will become even less profitable > because there will be even fewer responses - we'll > never know what's possible if we don't try > > >encrypting for each of the list recipients is too > >much of a burden for the list > > solution - don't encrypt, only digitally sign - > not a burden > > >Don't get me wrong: encouraging people to use pgp > >is a good idea, but making it a requirement before > >accepting it is a policy decision that the end > >user should be making, not the list. > > solution - by only digitally signing it is > completely up to the end user to decide whether or > not to add this tool to their anti-spam toolbox > > >Your proposal is in line with some existing ones, > >at least one of which response to the seriously > >problematic key management issue. > > solution - non-local, centralized key management > is a huge problem, but key management isn't a > problem if the only important keys are your > personal ones and if you don't expect to be able > to instantaneously have access to anyone's public > key via a keyserver - keyservers aren't necessary > for folks who exchange email with primarily a > small group of people > > >I'm not saying to reject non esig mails, but to > >held them for approval by moderators... If you > >want your post to go through quickly, sign it... > >It would be a worthwhile incentive. > > sounds like a great idea, but this is in addition > to and isn't required for what i'm suggesting > > >Also note, there is an addition burden placed on > >end users who rely on receiving encrypted email in > >your proposal. Under your scheme, a user has to > >go through the trouble of decrypting the message > >just to see if it is spam or not. This eliminates > >almost all forms of automated spam mitigation > >except those related to the low-level SMTP, DNS or > >other new authentication/authorization techniques. > > reminds me that signing and not encrypting still > allows bayesian filters to continue to be useful > > >Unfortunately, requiring that they have a > >published public-key *is* a burden to the average > >user. J. Random Luser just wants to sit down at > >his PC, boot up Winders, bring out Lookout, and > >forward a garish HTMLified email full of stale > >jokes to his buddies, complete with pictures, and > >he wants it to go through, without a hitch, right > >now. He thinks public keys are the ones hanging > >on the gas station wall, for the bathroom. He > >thinks crypto is someone from Superman's home > >planet. He thinks the IETF is them guys whut > >raided David Koresh. He has no clue what the ASRG > >is, but he thinks it sounds dirty. > > again, no need for keyservers for folks that are > exchanging email within a small group of people. > also, let's stop trying to allow email to continue > to be what it has evolved into, let those folks > that want email to stay the way it is keep it that > way, let's create a spam-free email environment > that works and satisfies *us*, i suspect that if > this is witnessed folks will eventually start > thinking of email differently as their personal > spam pain tolerances are exceeded. > > >Make it worth their while, by coming up with > >infrastructure such that they won't get any spam > >if they have a public key, and MAYBE they'll > >bother doing it, IF the ISP will hold their hands > >every step of the way (and not charge them too > >much, including for issuing new keypairs when they > >let the private ones slip out too much). Of > >course, this means that all their equally > >technically-enlightened friends have to know how > >to USE his public key.... > > solution - accept that it will be a gradual > process, let's just start with mailing lists > signing all messages that get sent to list > recipients - that's easy > > >This sounds very much like the use of extra > >headerz, or a password on the subject line, but on > >steroids. In the end, possibly useful, IF you can > >get everybody aboard, but they won't go until > >everybody ELSE is already on board, and meanwhile > >it's a pain in the proverbial posterior to > >everyone who wants to communicate with the people > >using it. > > for me it is *less* pain than what i'm > experiencing dealing with my current spam load, > and digital signatures can be ignored if you don't > want to verify them - also, if someone tells you > that they are receiving so much spam that you will > have to sign all email you send to them, are you > going to tell them they are causing you too much > pain? heck, just pick the phone up and call them > then. > > >Second, even if the above weren't a problem, one > >still has the problem that a virus infected user > >will still be sending messages, just like everyone > >else. > > this will still be a problem but with a digital > signature solution in place infected computers > will be identifiable and probably immediately > disinfected, folks will become hyper-aware of > allowing their machines to become compromised if > suddenly they are unable to exchange email with > their small and *important* group of people > because their public key became blacklisted by > these same folks - the very nature of digital > signatures positively identifies infected > computers > > >There is no scheme in which the rules can't be > >broken by someone intent on breaking them. The > >only path is to detect them, and prosecute them. > >In the case of spam, detection is easy, but not > >automatic. Prosecution is now possible. Its > >still a whack-a-mole game. It won't end unless you > >can get past the virus infection to the virus > >operator, and hopefully, there aren't really too > >many virus operators. Of course, we aren't > >stopping spam either in a very real sense, but > >rather abusers who are annoying and mailbombing > >people. But by my count of my inbox, if you stop > >those people, I can certainly handle the rest > >which amounts to maybe 1% of my current junk mail. > > there's no known way to crack GPG, widespread > adoption of digital signatures against spam will > either help bring spam to and end or tell us what > NSA might already know ;) - let's put those > spammers to work! also, prosecutions by a central > authority won't be necessary, peers will do the > prosecuting by rejecting email from compromised > systems, the owner of the infected system will be > de facto "punished" because communications with > their peers will end until they clean their system > (or stop spamming). > > >>The "for pay" idea is just another scam from > >>the people who would love to get a percentage of > >>the pay. While I'm sure Microsoft and others would > >>just love to get a cut of this (I know I would), > >>it doesn't do anything to stop spam, and if > >>implemented, would simply (and wrongly) charge > >>users whose computers were virus infected. > > > >Wrongly? I'm not so sure. Something ought to be > >done to stop the Typhoid Marys of the Internet. > >Putting them on notice that they WILL be held > >responsible for spreading the infection, or its > >effects, just MIGHT result in them FINALLY taking > >some responsibility for their "computer hygiene". > >Sure, there will have to be several well > >publicized example cases before most folk will sit > >up and take notice, but in the long run, it might > >be effective. > > i agree, trying to impose a burden > (computationally or monetarily) on spammers will > not work IMHO. i will leave it to others to > explain this in more detail. and to repeat, > prosecutions by a central authority won't be > necessary, peers will do the prosecuting by > rejecting email from compromised systems, the > owner of the infected system will be de facto > "punished" because communications with their peers > will end until they clean their system (or stop > spamming). > > >So even discussing adding a silly thing like > >mandatory esigs and encryption as an antispam > >measure is a waste of time, except possibly on a > >local basis. If I set up a small mailing list (or > >generalized group of individuals) and all of its > >members agree to do this, there is little > >"evolutionary pressure" for spammers to detect and > >foil our scheme and we will be "immune" (at the > >cost of a fair amount of extra work). If > >everybody does it and the automated tools for > >doing it without so much work are widely > >disbursed, they will develop countermeasures in no > >time at all and we'll lose our immunity. > > please explain how spammers will evolve past the > public key encryption technology used in digital > signatures? as noted earlier machine compromises > will still occur but they will be able to be dealt > with because peers of the compromised machine will > immediately identify and neutralize the problem by > ending communication (by blacklisting the > compromised key). suddenly the owner of the > compromised machine hears silence. > > >Automated text analysis will never be perfect, > >because even human text analysis for > >interest/disinterest (secretaries) aren't perfect. > >But it can help sort things. I hand filter about > >1500 messages a day. I get about 3500 over the > >weekend. Monday's filtering doesn't take me any > >longer than tuesdays filtering. > > unfortunately the approach you describe could > likely be your undoing in the long run as spammers > ratchet up the volume to the point were it *will* > take you a long time using this approach. this is > why even with 99.9% accurate bayesian filtering, > all spammers need to do is ratchet up the volume > to get more spam through the 0.1% error rate of > the bayesian filter. > > >>>Then using the IETF list as an example, you > >>>would need the entire list of recipients and their > >>>public keys, and you would need to send a message > >>>either directly to each of them, one by one, or > >>>send a single message with a session key for each > >>>recipient (thousands). This isn't going to work. > >> > >>Let's not mix apples with speedboats. These are > >>some options with the proposal: > >> > >>#1: no encryption is used either way, the list > >>address is in a whitelist for each recipient. > >> > >>#2: each recipient can only send encrypted msgs > >>(possibly, also signed) to the list, with the > >>list's key, for distribution. The listserver > >>verifies and resends the messages in plain text, > >>where #1 applies for each recipient. > >> > >>#3: the list receives messages as in #2 but the > >>listserver sends the msgs as encrypted mail to > >>each recipient, with each recipient's key. > > > >#4 (my preferred) the member send a message to > >the list with his digital signature. The list > >checks the digital signature (from keyserver or > >from a member database) and post the message if > >signature is valid. If the signature is not valid, > >the message is held for approval. But yes this > >scheme does not offer much more than restrict > >posting to list members only, which the IETF had > >to do last year(?). > > if the list server signs each message that then > allows recipients to positively identify mail from > the list. this is *HUGE*. if i have an email > account that only receives mail from mailing lists > that sign all messages then i can dump all > incoming non-whitelisted digitally signed email at > the server and *know* that all my email is legit. > > > > thread: ietf - how not to filter spam ----- > > >>first, there is an increasingly heated debate > >>between folks who want to sign the message (TEOS, > >>DomainKeys), versus others who want to secure the > >>channel between sender and receiver (RMX, LMAP, > >>SPF, etc.). > > > >What does it matter what the resolution is? > >Neither solution eliminates the spam channel, and > >solves the problem, as information theory shows. > >Its just a silly debate over two schemes to thread > >a needle that can't be threaded. > > think of spam as a river passing through multiple > channels, let's find a channel we can change. > folks talk about spammers taking advantage of > email protocols. another angle is to say that > spammers take advantage of people's behavior. > it's much easier to change my personal behavior > and expectations with regard to email than it is > for me to change an established internet protocol. > so stop thinking about eliminating the ability to > send spam and focus on *absolutely* identifying > real email. spam will dry up as people are able > to absolutely identify real email. > > >>That sounds like the old "authentication solves > >>spam" hope. It was wrong before SMTP-AUTH and it > >>is still wrong. > > > >Guess what, it is impossible to "solve" spam the > >same way it is impossible to "solve" burglary. At > >least with authentication you get to have > >whitelists that work. If you get a message with my > >email address in the "from" line it could be from > >anyone. If it is signed with my PGP key you know > >it came from me personally or someone went through > >a LOT of trouble to get access to my private key > >and the key phrase. > > > >The usefulness of authentication could be further > >extended by building a web of trust where people > >vouch for the fact that others aren't spammers. > >Obviously spammers will slip through from time to > >time, but anyone who spams or keeps vouching for > >spammers will be removed from the web of trust. > >But even if this part doesn't work authentication > >is still useful. > > exactly > > > > thread: tidbits - digital signatures in tidbits -- > --- > > >As I said earlier, I don't see the point of doing > >it for this list, but the mechanism itself isn't > >so easily spoofed. Think of it as an address > >based whitelist with addresses that can't be > >forged. A spammer wouldn't be able to get his own > >public key on the whitelist, and can't pretend to > >be someone else because he doesn't have the > >corresponding private key. I personally wouldn't > >use such a system, since the Bayesian spam filter > >I use (bogofilter) works well enough, but people > >that are more annoyed with spam than I get might > >find such a system attractive. > > exactly, my bayesian filter (POPFile) works great, > but i get so much spam that the 1% of my email > that doesn't get classified correctly is causing > me too much pain. > > >>>Then you have to start allowing attachments on > >>>the list...not a great idea. > >> > >>Not necessarily. This should work as text only > >>with PGP 8. > >> > >>Attachment converted: HHBV HD:PGP.sig (pgDS/---- > >>) (002B8C8F) > > > >Obviously, it does not work except by allowing > >attachments... and it's hard to believe that > >TidBITS Talk would ever come to that. > > no, digital signatures can be inline, the mime > attachment method is more robust but not required. > so tidbits can be signed without mime > attachments. FWIW, most email clients do support > the mime method. > > >>There are plenty of uses for digital > >>signatures, but I don't think approving mailing > >>list postings is likely to be one of them any time > >>soon. > > > >Agreed. Remember the messages that slipped > >through were approved by Adam because of poor html > >formatting, except one that forged his email. If > >he used digital signatures most of those messages > >still would've been signed, and just like Habeas > >headers, if you're spam filter auto-whitelists > >signed messages they would come through. > > exactly, if the list is signed spam can still get > through. what the signature does is allow the > mailing list traffic to be positively identified > amidst the personal flood of spam many folks > receive. just like we help list maintainers out > by taking extra steps to allow posting, > maintainers could help us out by signing all list > messages. dealing with spam requires cooperation. > > >>I think people should sign all of their > >>messages. That will have several effects: - Peole > >>will get suspicious if a message isn't signed, > >>making forging mesages harder. > > > >How do you handle email from a kiosk, or a cell > >phone, or someone else's computer? There are too > >many instances in the real world where this > >happens. It's one of the benefits of IMAP..you > >don't HAVE to be on any particlular computer to > >get your email. > > by locating signature verification at the mail > server level. create a procmail recipe that will > automatically tag all signed email as to whether > or not the signature exists in the personal > whitelist that has been uploaded to the server. > > >I do think we're getting off topic but -- any > >modern approach to the spam problem must take into > >account the fact that at any given time the > >Internet contains millions of insecure computers > >that can be taken over by viruses and used as > >zombies to, among other things, send spam. If > >digital signatures were actually used in some > >standardized way, it would be trivial for the > >virus to grab it and sign its messages. > > again, digital signatures as an anti-spam > technology will be effective for folks who don't > *need* to be able to be contacted by anyone on the > internet prior to them verifying they're not a > spammer. folks that need to be this accessible > need to either modify this requirement, continue > to rely on statistical spam filtering tools, solve > the key distribution problem, and/or work to > change established internet protocols. > > >This assumes that you already have all the keys > >of potential correspondents in your keyring, > >which makes this just another form of > >whitelisting, albeit a cryptographically secured > >one. The shortcomings of whitelisting systems are > >well described here and elsewhere, but basically > >you'll have to read all your (signed) spam just to > >make sure there isn't a message there from someone > >you haven't whitelisted yet. Remember, too, that > >public keys really should expire, so you would > >need a method for keeping your whitelist (keyring) > >up to date. If you try to automate the whitelist, > >you open the door to spammers again. > > you are assuming the receipt of email from a large > previous unknown group of entities. if this is > you then you won't benefit from digital signatures > adopted on a small scale. but if you are one of > the many folks who only receives email from a > small group of people then digital signatures > ensure that you will never miss one of their > messages. > > >I'm a big proponent of cryptographic signatures; > >they just aren't the Final Ultimate Solution to > >Spam. > > digital signatures don't do anything whatsoever to > end spam - they allow spam to be sent to > /dev/null > > >Whitelists work great for those corresponding to > >just a few people. But they simply aren't pratical > >for participation in mail lists. > > at the very least a digitally signed list (by the > list software/moderator) allows list recipients to > identify list traffic. i do have my doubts about > how impractical it would be for the list > software/moderator to check for digital signatures > prior to posting messages from list members. > think gradual implementation, let go of the notion > of all members signing their posts, although they > might, and for every list member that does sign > that's one less post to be analyzed to see if it's > spam. > > >>Whitelists work great for those corresponding > >>to just a few people. But they simply aren't > >>pratical for participation in mail lists. > > > >Sure they are. You are missing the whole point of > >how digital signatures would/should be > >implemented in a discussion list environment. > > > >It's not the end user who needs to verify the > >signature, it's the list processor. > > > >I subscribe to a list. As part of that process I > >provide the public half of my key. Any message I > >submit to the list is signed by me using my > >private key. The list manager software then > >verifies my signature and passes the verified > >message on to the list or to the list moderator. > >This ensure that only messages written by bonefide > >members of the list get past on to the members of > >the list. > > > >The whole point is not to ensure that messages > >coming from the list are signed but to ensure that > >messages submitted to the list are signed. > > > >This also obviates the need for the list to > >support attachments and makes pgp/mime a BETTER > >alternative to inline signing. The list processor > >receives the messages, verifies the signature and > >strips the signature. I, as a subscriber to the > >list, never see the signature. > > > >Maybe, the list processor itself signs the > >messages it sends out. In which case I only need > >to have the one key (the public key for the list) > >in my keychain. > > well said. i differ only in that i would start by > having the list processor sign the list (what i > perceive to be a simpler yet positive step) rather > than trying to get list members to sign in order > to post. > > >If we stop all counterspam measures by pointing > >out that they aren't the Final Ultimate Solution > >To Spam (TM), the situation will never improve. > > here! here! > >
