Subject: Re: [Asrg] subverting ISACS

From: "Michael Kaplan" <[email-masked]>
Date: Wed, 12 Jan 2005 00:13:53 -0500

----- Original Message -----
From: "Laird Breyer" <[email-masked]>
To: [email-masked]
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
> [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.

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Laird Breyer <[email-masked]>
Date: Wed, 12 Jan 2005 16:13:03 +1000

On Jan 12 2005, Michael Kaplan wrote:

> Mailing lists operators should make it clear that if a sub-address
is deactivated then the onus in on the subscriber to re-register.

I agree this is necessary in this case.

> 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.

Doing this once in a while is not difficult, doing this regularly is
disruptive and a chore, unless it can be suitably automated. 

> 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.

That's correct. Most people have a vested interest in keeping the same
email address once several people have been informed of it.  Moreover,
in the case of mailing lists, changing your address regularly prevents
people from replying privately to you. If all you do is lurk, this isn't
a problem.

A better answer is to filter the content of the incoming mailing list
stream.

> 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.

Currently, the answer is to content filter the list, either through
moderators, or using software filters. The accuracy is likely similar
(filtering lets some spam through, reregistering implies some spam
getting through to prompt the registration), but the current answer
doesn't require active participation by users.

>  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

Yes, this happens with public archives and logs, but I don't think that
ISACS is less vulnerable to spam originating from mailing lists. So
long as you stay subscribed to a public list, ISACS lets through all
the spam sent to that list, no matter how many times you resubscribe.

It's a Sysiphean task. In the event of wide deployment, users of ISACS
learn to generally deactivate a subaddress whenever it starts collecting
spam, but if the address is a mailing list rather than an
individual's, this behaviour is useless. 

Thus every piece of spam sent to a mailing list still has a human cost:
the cost is either borne by the subscriber, who re-registers often, or
by the list operator, who loses subscribers or re-registers them.
These costs also exist now of course, but it's not clear to me that 
ISACS by itself reduces them in relative terms.

-- 
Laird Breyer.