ietf-asrg
[Top] [All Lists]

RE: [Asrg] Spammer proxies using legitamate mail relays

2005-02-15 23:01:27
-----Original Message-----
From: Jonathan Morton 
[mailto:chromi(_at_)chromatix(_dot_)demon(_dot_)co(_dot_)uk] 
Sent: Tuesday, February 15, 2005 9:29 PM
To: George Ou
Cc: ASRG
Subject: Re: [Asrg] Spammer proxies using legitamate mail relays

---SNIP----
Have a think about the following scheme, then, which I'm in the process of
implementing.  If you can, I'd like you to point out any chinks in the
armour.

You've heard of hashcash, naturally.  As a proof-of-work system, it is
simple in concept - physically prevent spammers from being able to generate
lots of (deliverable) mails per second per host, by chewing up their CPU
time.  The disadvantage of hashcash, when used on it's own, is that it also
limits the rate at which legitimate mails can be sent.

There is also the concept of whitelists.  However, addresses can be spoofed
in today's e-mail, so conventional whitelists can be circumvented by
plundering the address book from a zombie and doing a bit of guesswork.  One
solution is to use a cryptographic signature, unique to the sender/recipient
pair.  This still leaves the introduction problem - how do you get on the
whitelist and hand over the signature verification keys?

The solution is to allow a signature *or* a hashcash token to get a message
past the filter.  The first messages of an e-mail exchange contain hashcash
tokens, which are expensive enough to prevent spammers from flooding inboxes
as they do today (with today's estimated zombie population, that means 27
bits or more).

In this first exchange, signature keys are also exchanged, and are used for
computationally-cheap conversation subsequently.  The protocol would ensure
that only genuinely two-way conversations would be able to set up signature
relationships.  The signature relationship involves a pair of asymmetric
key-pairs, one for each direction of message flow.  
The private key is, of course, used for signing, and the public key for
verification.  There is no relationship between the body of the message and
it's signature - the signature merely has to be unique for each message, a
fact which is enforced using a double-spend database just like hashcash.

Because of Moore's Curves, the threshold value of the initial hashcash token
would have to be increased over time, by approximately 1 bit every 18 months
if past trends continue.  This can be accomplished either by application of
an internal date-based formula, or by occasional reference to a DNS entry,
or else by a manual configuration entry (the latter is discouraged).  This
factor I believe is manageable.

A further problem is that some situations have limited processor power, but
still need to send mail to a diverse range of recipients with tolerably low
latency.  Sales and tech-support desks would be good examples, as would the
low-power mobile phone.  Solutions include a "captive zombie" approach where
hashcash stamp production is intentionally farmed out to all workstations in
the department, reducing latency but not affecting total throughput - if
businesses really don't want to subscribe to the thin-client model, they
might as well harness the benefits of the fat-clients they already have.
The solution for mobile and thin-client situations is to have stamp
production done (possibly for a fee) by a server farm just upstream of the
client.

The remaining problems centre on mailing lists and legacy users.  I'll deal
with mailing lists first.  The obvious solution is to have the listservs
implement the scheme natively, and benefit from the stronger subscriber
authentication.  A signature relationship can be defined during the standard
double-opt-in process, obviating the need for the listserv to generate
hashcash many times for each message it processes. 
  A listserv that doesn't implement the scheme should look just like any
other legacy user, whom we will now deal with.

Legacy users are a sticky problem - literally.  However, we can consider the
hashcash and signatures as acting like a bypass mechanism. 
  Messages without valid hashcash or a valid signature are directed into a
content filter.  Because there is now a foolproof way to avoid being
processed by that filter, it can be a lot more aggressive than usual, thus
reducing false negatives.  Eventually, when participation is sufficiently
high, it could become a straight blackhole.

To help participation figures, Eric and I have been considering how to get
the ISP involved, seeing as MUA plugin systems are presently highly
proprietary and thus hard to deploy rapidly.  The easiest solution seems to
be to install a daemon on the user's machine, which stays in contact with
software attached to the ISP's MTA.  The latter then notifies the former
when it receives a message from the user that requires hashcash, allowing
the user to accelerate delivery far more than the ISP would economically be
able to do alone.

The software attached to the MTA would take over hashcash production
(generally at a much slower rate) if necessary, and also handle all
signature and filtering duties - thus ensuring that all clients of the ISP
participate in the scheme.  This is, of course, best combined with SMTP AUTH
to prevent zombies from exploiting other clients of the same ISP.

For the avoidance of doubt, the working title is, at present, RubberStamp.

---SNIP----

Most effective anti-spam systems already implement a wide range of every
practical anti-spam technique available and are always in a state of
evolution.

Most hashcash proponents are already for a hybrid system that would skip the
computationally intensive part for relatively strong authenticated senders.
For example, senders from reputable domains that comply with SPF and/or
SenderID or maybe even domain keys should be allowed to skip hashcash.  For
bulk senders, they should have to have a registered (or bonded) domain using
DomainKeys because of it's non-repudiation for any spam they spew.  For all
other email that hasn't been verified by SPF/SenderID/DomainKeys, they
should be brutally punished with a one minute computation (on a dual 3.6 GHz
XEON box) for every message they want to send.  If they don't want to
compute it, too bad.  The only problem for hashcash is that spammers already
have a massive SuperGrid available to them in the form of Zombies that
currently act as SMTP proxies.  I guess that means we'll either need to flag
them as suspicious and place the messages in a quick flush folder or we'll
just need to drop them.

As for Moore's law, the major CPU vendors have been in violation of it for
nearly 2 years now.  Intel's been stuck in the 3 GHz funk for 2 years now
and they're going to start resorting to multi-cores like every other CPU
vendor.

Bottom line is, anti-spam technology is getting better but the spammers are
still one step ahead.

George


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg