Re: [Asrg] request for review for a non FUSSP proposal

Rich Kulawiec <rsk@gsp.org> Tue, 23 June 2009 20:37 UTC

Return-Path: <rsk@gsp.org>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305CA28C3E7 for <asrg@core3.amsl.com>; Tue, 23 Jun 2009 13:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.442
X-Spam-Level:
X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02CmFhv0DfUO for <asrg@core3.amsl.com>; Tue, 23 Jun 2009 13:37:45 -0700 (PDT)
Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 10C0E3A6A89 for <asrg@irtf.org>; Tue, 23 Jun 2009 13:37:44 -0700 (PDT)
Received: from squonk.gsp.org (bltmd-207.114.17.162.dsl.charm.net [207.114.17.162]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n5NKbxvv005084 for <asrg@irtf.org>; Tue, 23 Jun 2009 16:38:00 -0400 (EDT)
Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n5NKXP5U003380 for <asrg@irtf.org>; Tue, 23 Jun 2009 16:33:25 -0400 (EDT)
Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n5NKbrwG015115 for <asrg@irtf.org>; Tue, 23 Jun 2009 16:37:53 -0400
Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n5NKbrTJ015114 for asrg@irtf.org; Tue, 23 Jun 2009 16:37:53 -0400
Date: Tue, 23 Jun 2009 16:37:53 -0400
From: Rich Kulawiec <rsk@gsp.org>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Message-ID: <20090623203753.GA14617@gsp.org>
References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <20090622215251.GA2137@gsp.org> <4A400246.9060103@telmon.org> <20090623100542.GA9628@gsp.org> <4A40B2C0.8090604@telmon.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A40B2C0.8090604@telmon.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [Asrg] request for review for a non FUSSP proposal
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2009 20:37:46 -0000

On Tue, Jun 23, 2009 at 12:47:28PM +0200, Claudio Telmon wrote:
> While what you say is true in general, I think you missed a critical
> part of the consent framework I'm proposing. A consent-enabled address
> will only accept messages from senders that received a valid token for
> that address though some channel (usually, not email).

Yeah, I get that.  But whatever that channel is, if it ultimately connects
to a network endpoint that's compromised (more and more likely every day),
or if it originates on a network endpoint that's compromised (likewise),
then whatever is communicated via that channel can't be trusted.  Moreover,
even if the information that's communicated via that channel is authentic,
any compromised endpoint can't be trusted to act on it properly.

Maybe I'm not saying this very well.  Let me try examples: Fred
doesn't know Barney, but gets a request for consent: it looks plausible,
so he grants it.  But the request *wasn't* from Barney, it was from
the malware on Barney's laptop, and now Fred not only has to deal with
the spam, he's got to revoke the consent.   Or: Wilma knows Betty,
and sends a request for consent.  Betty grants it, and things go
fine, until the night Wilma's system is compromised and sends a dozen
pieces of spam to Betty, who wakes up to it.  (Why does this happen?
Because the malware resident on Wilma's computer read the list of
people-who-have-granted-consent-to-Wilma and targeted that first.)

And so on, for all kinds of scenarios we could come up with.  Yes,
this is not a big problem for Fred or Betty, but when we multiply
them by a hundred million, it's a pretty big problem.  Which is why
this idea sounds to me like an attempt to build a layer on top of
a computing base (end-user systems) that are already compromised
in enormous numbers.

> With respect to consent-enabled addresses, it would turn
> the problem of informing the owners of millions of compromised systems,
> into a "local" problem of relationships inside small groups of people.

I don't think so: there is no "local".  Take for example, the members
of this mailing list: presuming that all of us use a mail client which
maintains an "address book" (and I don't) I'm certain that every one
of us has at least one entry in it that nobody else on this list has.
Most of us probably have *many* entries that nobody else on this list has.
And some of those entries are mailing lists which forward to many people.
Consider the extent of the damage that could be done if one of our
systems started spewing -- and how many spam recipients would have to
individually act in order to fully mitigate it.  (Because A and B
revoking their consent to mail from Z does not help C, D, E...)

(Which raises another scalability question: how would those of us who
have hundreds or thousands of correspondents find the time to manage
all this?  And any of us participating in any mailing list have many more
potential correspondents: anyone on any of those lists might write to us
off-list.  Same for anyone with a web site or blog or running any other
resource.   A quick check of my personally-addressed and valid inbound mail
-- that is, not including mailing lists, not including spam or phishes --
suggests that I've had over 11,500 correspondents in the past few years.
That's a lot of tokens to keep track of.  And that's just *me*.)

Moreover, "informing the owners" has already proven to be a badly-losing
strategy.  *If* the owners actually receive such communication
(telling them their system is probably compromised), they tend to
either disbelieve it, ignore it, classify it as a phish--often correct,
deny it, or act ineffectively to remedy the situation.  No anti-spam
scheme which requires effective, clueful participation by end-users has
any chance of working: if they existed (in very large numbers) then we
wouldn't have such a large spam problem because (a) their systems would
be compromised in huge numbers and (b) they would have learned by
now to never respond to any spam.

---Rsk