Re: digital signature request

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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: <gnulinux@xxxxxxxxxxx>
To: <ietf@xxxxxxxx>
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!
>
>



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]