ietf-asrg
[Top] [All Lists]

Re: [Asrg] Re: 3. Proof-of-work analysis

2004-05-24 06:24:14
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In article <40B1BDED(_dot_)6080203(_at_)cypherspace(_dot_)org>, Adam Back
<adam(_at_)cypherspace(_dot_)org> writes

Richard Clayton wrote:

it does _not_ affect our analysis based on use of zombies  

I'm wondering about the zombie argument.  So clearly it is valid,
spammers can and do obtain zombies through viruses etc.  

If you include insecure end-users along with the zombies, then you're
looking at a very substantial part of the current problem. I've seen
estimates of 70%

However it is
somewhat demanding of a threat model on any anti-spam system to say that
it should remain secure if the spammers 0wn some significant fraction of
user machines.

I think it is important that we use a threat model that is a good
approximation to the Real World, not just one that a particular system
is good at countering :)

It seems quite realistic to assume that there are currently several
million machines which are 0wned by the bad guys. I can see nothing on
the horizon that suggests that end-user security is going to undergo a
major step change this decade ... so we must plan to cope with this sort
of level of problem.

Viewing these numbers as a fraction (circa one in two hundred) is not
very illuminating -- the total number is more significant. However, it
does show (because you need to deal with more than 199 in 200 people)
the sort of penetration you need for education or platform change or
whatever solution you think will effectively address the issue.

For example consider the following anti-spam systems and the effect of
owning the machines:

- signature based / verified sender -- broken, spammer just installs
malware on zombie which abuses the users credential

yes indeed -- and if there is money involved (paying per email, paying
for certs which then get revoked when the credential is misused) then
you end up with a million or more very unhappy people...   now you might
imagine them ganging up on their service providers (hardware, software,
connectivity) but that just means that the whole community eventually
bears the cost since it will not be coming from the insecure
individual's pockets :(

- white-list based -- broken (more limited perhaps can only reach the
set of users who have white-listed the zombie owners) spammer harvests
white-listed pairs of addresses and optionally sends from the same
zombie harvested from.  (You see this with the virus payload that sends
from random pairs from address book -- where you frequently receive
virus propagation and/or spam mail from people who's email addresses
your recognize.)

there seems to be an assumption that <n> spams will come from <n>
different senders and hence there must be <n> whitelist entries...

... why should the spammmers (who provide a service to many clients) not
set up <1> whitelist entry for <1> sender and still send you <n> spams

If they have many millions of sender machines you won't spot the pattern
in people requesting whitelist relationships with you :(

Of course clever designs will address this, but only, I suspect at the
cost of significant human decision-making input :(

likely similar problems apply to most other anti-spam approaches if the
person you are defending against 0wns lots of machines.

so perhaps that means that spam won't have a technical solution ?  That
conclusion doesn't faze me, but clearly it upsets many technical people
who provide solutions in other spheres and would like to provide one
here :(

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBQLHtYhfnRQV/feRLEQLwIACgiar5ABrU+uhtDfj8Pgi/6y8kuhkAoOKV
KmqH6YsegM/A5CJQ5mwiVTZr
=Cwm6
-----END PGP SIGNATURE-----

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