----- Original Message -----
From: "Laird Breyer" <laird(_at_)lbreyer(_dot_)com>
To: asrg(_at_)ietf(_dot_)org
Subject: [Asrg] subverting ISACS
Date: Wed, 12 Jan 2005 13:17:51 +1000
Since we've been discussing ISACS a lot, I'd like to propose a general
strategy of subverting the system to induce denial of mail service and/or
increase mail traffic.
To summarize the relevant bits of ISACS: every user has unlimited email
addresses consisting of a unique prefix followed by a variable "password"
section. A sub-address (which consists of the prefix and some "password")
can be turned on or off, resulting in email sent to that sub-address being
accepted without checks, or being blocked.
When an email to a sub-address is blocked, the sender must solve a
challenge which proves his humanity, and is recompensed with a new
sub-address which doesn't block any mails sent to it. This sub-address
can be turned off subsequently etc. Michael Kaplan proposed sending
the challenge by email to the purported sender, while Peter Holzer proposed
a modification, where the sender is responsible for requesting the challenge.
A weakness of this scheme is that when receiver R distributes a new
sub-address to sender S, there is implicit trust that S would not send
unwanted email. This is enforced by turning off the sub-address if
S transgresses the covenant.
To subvert this scheme, we want to
1) ensure that S breaks the covenant with R,
2) ensure that the act of turning off the sub-address has repercussions to
"innocent" people.
We can obtain 1) by letting S be a public mail expander, such as this
ASRG mailing list. Since anybody (more or less) can send mail to
asrg(_at_)ietf(_dot_)org, someone can send spam, which will be distributed to
all
list subscribers. Thus S, which normally sends ASRG discussions to R, now
also sends spam.
To obtain 2), it is clear that the act of turning off the sub-address
only directly affects those senders who can use this sub-address by
actually knowing it. However, this can be leveraged if we consider
that R turning off the sub-address changes the behaviour of S, which
in turn affects those who depend on the behaviour of S, etc. If S is
a mailing list, then a change in behaviour of S affects all its
subscribers.
We now have a recipe: pick a public mailing list S and assume most of
the subscribers implement ISACS. Send a single spam message to S,
which arrives in each subscriber's mailbox. Each subscriber
consequently disables the sub-address originally given to S. Now S
must expend time and effort to solve a challenge for each subscriber
of the list.
But S loses whether it succeeds in solving all challenges or not. In
the former case, much time and effort was wasted due to a single spam
message sent to S, and in the latter case the list has lost a
substantial fraction of its membership as a result of a single spam
message, even though the affected users have not formally asked to be
unsubscribed.
Worse, the original member of S who sent the single spam can repeat
his attack regularly and at times of his choosing, thereby effecting
this kind of DOS over and over. This results in potentially unbounded
losses to the S operator.
For example, in the case of the ASRG list, anti-spam discussions could
be effectively censored forever by sending a trickle of spam messages
regularly. Every spam sent would result in a cost of a few dollars to
the ASRG operator, while the spam itself costs essentially nothing.
All sorts of variations are possible so long as 1) and 2) are obtained.
--
Laird Breyer.
That was an excellent synopsis of ISACS.
The scenario you describe doesn't seem to be how a spammer could subvert ISACS
to send spam. You describe how a malicious person may attempt to reduce
confidence in ISACS, and thus only help spammers in a very indirect way.
For one thing I think it would be atypical for mailing list operators to
actually try to decode bounces. If I start to receive a flood of spam to the
email address I'm using now then I would just get a new email address and
re-register with the ASRG. Mailing lists operators should make it clear that
if a sub-address is deactivated then the onus in on the subscriber to
re-register.
The rational behind your example seems to be this:
With ISACS it is so easy and non-disruptive for a user to deactivate a single
sub-address that they will instantly deactivate the sub-address given to a
mailing list in response to a single piece of spam. They then won't bother to
re-register, expecting the list operator to assume the burden of decoding the
CAPTCHA in the bounces.
Your rational also seems to be that this doesn't happen with the current email
system because it is too inconvenient and disruptive for a person to abandon
their current email address in response to a moderate amount of spam, therefor
the person will be forced to keep their current email address active (to the
benefit of the mailing list). Also if users of the current email system do
abandon their accounts then they will always re-register since obviously there
is no CAPTCHA being sent out for the list operator to decode.
I think that in reality subscribers who use ISACS will know that they will need
to re-register with the mailing list in such a situation.
The current email system is much more vulnerable such purely malicious attacks.
One could just maliciously post everyones email address on the internet for
easy spam bot harvesting. ISACS would really mitigate the damage that this
vandalism would inflict. Under the present day system people receiving spam
will never even know that they are receiving spam as a result of the public
mailing list leaking their address, and cancelling your email account would
disrupt all of your contacts.
I believe that your example serves to highlight the strength of ISACS.
Michael Kaplan
--
_______________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg