Subject: [Asrg] subverting ISACS

From: Laird Breyer <[email-masked]>
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
[email-masked], 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.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Seth Breidbart <[email-masked]>
Date: Tue, 11 Jan 2005 23:00:10 -0500 (EST)

Laird Breyer <[email-masked]> wrote:

A way to break ISACS by spamming mailing lists.

It isn't quite that simple, though; if a user of ISACS turns off the
subaddress used by a mailing list, he should unsubscribe and
resubscribe a new subaddress.  This puts the work where it belongs, on
the user of ISACS.

Of course, it doesn't matter: the spammer will just spam the list
again.  So the users of ISACS won't (effectively) unsubscribe from the
list just because it gets spammed, but will decide how to deal with it
the same way everybody does now.

Seth

---

From: Laird Breyer <[email-masked]>
Date: Wed, 12 Jan 2005 14:40:23 +1000

> resubscribe a new subaddress.  This puts the work where it belongs, on

I agree. However, the simple act of turning off the address still
automatically send a challenge back to the list address even if the
user unsubscribes and resubscribes afterwards. So ISACS now has to have a
subsystem for dealing specially with mailing lists, or else the user
should bypass ISACS, unsubscribe/resubscribe *first*, then
turn off the subaddress, all of this manually.

In Peter's variation, simply turning off the subaddress could be
undetected, resulting in loss of service to the subscriber contrary
his expectation, or if detected it's still a cost to decode the
challenge. I'd expect list operators to not request the provided
challenge URL as a matter of policy.  So the user would, by turning
off the address, still obtain an unexpected side effect: losing access
to the list. This is unexpected because, if ISACS is widely deployed,
then the act of turning of a subaddress for one to one email
simply induces the sender to retry.

> the same way everybody does now.

If ISACS users must pre- or post-filter all their mail independently
from the ISACS system, a legitimate question becomes what ISACS brings
to the table in that case.

-- 
Laird Breyer.

---

From: Seth Breidbart <[email-masked]>
Date: Wed, 12 Jan 2005 19:52:01 -0500 (EST)

Laird Breyer <[email-masked]> wrote:
> user unsubscribes and resubscribes afterwards.

Why?  How?  The challenge doesn't go back unless the list sends to the
turned-off address, so unsubscribing, resubscribing, and then
turning-off would be the preferred order.

> So ISACS now has to have a subsystem for dealing specially with
> mailing lists, or else the user should bypass ISACS,
> unsubscribe/resubscribe *first*,

That's right.

> then turn off the subaddress, all of this manually.

Or do the unsubscribe/resubscribe "off to the side".

But in reality, this is no worse than any other whitelisting system
that whitelists mailing lists.  If a spammer sends to the list and the
spam gets forwarded, it gets through.  BFD.

> to the table in that case.

It's a method of whitelisting, that's all.

Seth

---

From: Laird Breyer <[email-masked]>
Date: Thu, 13 Jan 2005 11:49:52 +1000

> turning-off would be the preferred order.

Yes. It's not difficult to do this right (or wrong), it's just
different from dealing with an address belonging to a single person.

We're finding that ISACS users need to treat mailing list addresses
differently from personal addresses, for if they treat them the same
way it causes side effects and can be exploited as per the example.
Similarly, list operators must treat ISACS users differently (ignoring
or blocking challenges say) or bear possibly unbounded costs.

The point of this subversion exercise is to imagine common scenarios
and apply the proposed method. If amendments or constraints are found,
these had better be known, and will be relevant when comparing with other
spam solutions.

For example, software spam filtering methods (as a counterexample)
don't require special treatment of mailing lists. 

-- 
Laird Breyer.

---

From: Seth Breidbart <[email-masked]>
Date: Wed, 12 Jan 2005 22:19:30 -0500 (EST)

> don't require special treatment of mailing lists. 

Depends on the mailing list.  You certainly wouldn't want to block
spam from the list that abuse@<provider> feeds.

Seth

---

From: Laird Breyer <[email-masked]>
Date: Thu, 13 Jan 2005 13:48:07 +1000

> spam from the list that abuse@<provider> feeds.

How does that require special treatment? The filter mechanism
functions in exactly the same way whether the mail was sent to abuse@
or any other address, namely it filters what it considers spam.

If you are saying that you don't trust a filter to handle abuse@,
that's perfectly valid, but I can't see how this requires special
behaviour by the filtering technology itself?

By contrast, consider the ISACS spam filtering mechanism: it functions
by turning off a sub-address once it collects enough spam. But this
mechanism must depend on the nature of the address to prevent network
side effects.

Looking at it another way, you are of course free to *not* use a
software filter for abuse@, as you are free to *not* use ISACS for
mailing lists. But if you do, then the software filter mechanism can
be independent of the nature of the address, while the ISACS system
mustn't.

-- 
Laird Breyer.