RE: CAPTCHA over smtp (yet another spam solution to discuss)

Joachim wrote:

> Seth Goodman wrote:
>
> > small payments that are necessary in hash-cash and similar schemes.
>
> hash-cash == use CPU cycles rather than money
> That's got nothing to do with PayPal.

"hash-cash and similar".  Micropayments are meant to accomplish the same
thing as CPU cycles, which is to shift cost from the recipient back to
the sender.  Neither hash-cash nor micropayments has been made to work
thus far, and some say they never will.


> You just raised two red flags:  Identifiability of senders (that we
> can do without in money schemes) and ...
> ... the impossibility of "freeBay."  eBay reputation works (often
> enough) because of the cost associated with a transaction, which
> disincentivizes people from generating "feedback spam."

If you must present the digest of an actual message you received and the
address it was sent to, as well as prove you are the recipient, it's
unlikely for you to get inappropriate ratings.  I'm not advocating this
particular scheme, just saying that reputation can be very useful.  It
is likely a requirement to facilitate communication among people who do
not yet know each other.


> [By subverting the security of electronic payments, spammers could
> happily continue their business.]
> > > The difference being, the spammer's victims aren't compensated
> > > (today). Which has to do with the fact that credit cards are
> > > inherently insecure, which results in high transaction costs.
> >
> > The cost of credit card fraud is born largely by the merchants who
> > receive chargebacks, neither by the credit card processors and nor
> > by the people who's cards are stolen.  Fees in the credit card
> > business don't have a lot to do with actual costs.
>
> The cost of credit card fraud is borne by insurance.  Maybe by the
> self-insured merchant.  Whether it's an insurance premium or the
> expected loss in credit card fraud per $1 of turnover, merchants will
> put it on the price.

Self-insurance == no insurance in common parlance.  Insurance is a way
to share risk in order to make it possible to undertake activities where
random losses would be catastrophic to small groups or individuals.  I
think it would be completely self-defeating if spammers could push off
the cost of their fraudulent escrow deposits onto legitimate
participants.  If most spammers did that, we'd be back to exactly the
situation we have now.


> And yes, major credit card companies do offer to "protect" (i.e.,
> insure) you as a merchant.

The merchants I know would disagree.  They are forced to eat all the
chargebacks, some of which occur several weeks after the transaction is
authorized by the payment processor.  I'm only arguing that for a
payment system to work in this context, it needs the attributes of cash.
A bond must be worth something.


> > Even greylisting, which is a minimally intrusive form of C/R, has
> > only gained a minor following.
>
> Right, greylisting.  Without having any numbers, my guess is that
> greylisting has become pretty pervasive.

Your guess would be incorrect.  It is common, but still only used by a
minority of sites.  It protects against one specific kind of spammer,
and if greylisting ever does become widespread, it would be easy for
spammers to adapt.  The only cost to spammers to defeat greylisting is
to resend a spam, any spam, to the same sender-recipient address pair
from the same originating IP.  There's no need to cue messages, just the
address pairs from a particular zombie host.


> Sending a message (an email) back to "implement" C/R completely misses
> the point.  You blindly trust the envelope sender, and you emburden
the
> sender with things that could be automated.  (qsecretary, anyone?)

Your points are valid, and qsecretary is indeed a PITA.  Using ordinary
email for C/R is a poor solution, and it is what most people think of
when you say C/R.  Which leads to your observations ...


> This all tries to answer the question, how can we be sure to not spam
> an innocent victim by sending a challenge as a fresh email?

If a system meant to curtail network abuse necessarily perpetrates abuse
on others, it has already failed.


>
> Maybe most importantly, I think there may be good reasons to send
> email anonymously.  Not that this necessarily worked today, but one
> fundamental flaw in "sending email challenges over email" is that this
> can only work if the recipient finds a good email address in the
> incoming message to send the challenge to.  In other words:  No email
> must ever be anonymized.  Ouch.

Depends on how you look at it.  I think it's unclear whether anonymous
email is necessary.  While desirable in a few cases, it could be
provided in those limited contexts.

There are a lot of precedents for giving up some anonymity for mutual
benefit.  It is clearly against the common interest to facilitate anyone
screaming "fire" in a crowded theater with complete anonymity.  However,
it is obviously in the common interest to permit people who saw a crime,
and who otherwise would not report it, to do so anonymously.  That
should trigger extra scrutiny, but it still serves a common purpose.

For similar reasons, we don't have the right to drive a vehicle down the
road without a license plate, nor can we make analog phone calls without
creating a record in a phone company switch.  When technologies have
been around a while, the theoretical benefits of anonymity are often
outweighed by practical considerations.  I am not saying full anonymity
is bad, only that I'm not sure.


> Then, there is the technical issue of consistently marking the
> challenge as such and as belonging to the original message.  These
> things all seem to be geared towards 100% backward compatibility.
> ("MUAs that don't know my C/R scheme [i.e., each and every MUA] will
> just forward the challenge to the user as an email.")
>
> In contrast, a "real" C/R email system would be much more like a phone
> call to someone with a secretary.  The secretary won't tire of
> accepting /many/ phone calls, even simultaneously.  The caller will
> be asked to jump through hoops (the nature of which is yet to be
> defined), depending on what kinds of hurdles the callee instructed
> the secretary to put before them.

If you take SMTP off the table, you can certainly imagine more
functional systems.  Whether you require anonymity is very fundamental,
as that changes the problem significantly.


> [Electronic signatures]
> > Electronic signatures are useful in exactly the same places as
> > handwritten signatures:  where you need a strong identity assertion
> > that is non-repudiable.
>
> And then, there's personal meetings.  Whatever you tell me in a
> personal meeting, feel free to later deny having said it.  Still, I
> would be confident that it was actually you who spoke when you said
> whatever you said.

As with all hearsay, two or three others present who report the same
version of the conversation as you do would make it hard for me to deny
it.  Depending on what it involves, the burden of proof can be fairly
low.


> Repudiably signing statements in a chat room is to offline signatures
> what a personal meeting is to handwritten signatures.

This could also be an ephemeral signature, where there is strong
validation by all parties at the session time, but not later.  The SSL
session is not a bad C/R model.


>
> > That is a small minority of documents, normally ones that must
> > survive legal challenge.  Besides, I'm not asserting that
> > "repudiability of authorship is a good thing".  If you intend to
> > repudiate authorship of something, better to not write it down in
> > the first place.
>
> People tend not to intend to repudiate their authorship.  It's just a
> property of a message exchange system that, when satisfied, implies
> that the intended recipient of a message can verify the sender's
> authorship, but nobody else can.

I see where you're going.  If preventing others from verifying the
sender identity is not a requirement, then ephemeral keys (session keys)
would also work.


> If I need to sign messages to you (either in OpenPGP or in S/MIME
> format) just so you can deem yourself allowed to send a challenge over
> email to me, anyone can verify my signature.

Is anonymity a general requirement?


> > Now if I sent a newspaper a legitimate message I received from
> > someone that although unsigned, still admitted to serious
> > wrongdoing, it would get a lot of attention.  As it should.
>
> Well, replace "$FELONY" by "$OBSCENITY" (which may be lawful).
> Either way, what if someone sent the paper an illegitimate message,
> though?

The newspaper should treat it like all circumstantial evidence and
attempt to corroborate it.  If they fail to use a reasonable degree of
care and print something that does harm, they may be liable for the
damages.


> > > [If a mailing list maintainer asserts Seth Goodman sent a message,
> > > that's at least as good as an electronic signature.  If not
> > > better.]
> >
> > This is a straw man.  A mailing list distribution will generally be
> > believed to be from the claimed author, as long as there is no
> > reason to distrust the mailing list itself.  There may be no proof,
> > but that isn't needed most of the time.
>
> Sure, /most/ of the time my snail mail arrives in evelopes that have
> probably not been steamed open before.  Should we all use postcards,
> hence?

That depends on the content and your personal desire for privacy.  For
parking tickets you'd find one set of preferences, for eviction notices
you'd find another while some things are unsuitable for mail at all.

--
Seth Goodman