ietf-asrg
[Top] [All Lists]

[Asrg] subverting ISACS

2005-01-11 20:50:21
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.

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


<Prev in Thread] Current Thread [Next in Thread>