Re: [Asrg] EPOSTAGE Too Big to Block?

John Leslie <john@jlc.net> Fri, 10 July 2009 17:26 UTC

Return-Path: <john@jlc.net>
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 70A9F3A6858 for <asrg@core3.amsl.com>; Fri, 10 Jul 2009 10:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.357
X-Spam-Level:
X-Spam-Status: No, score=-6.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 bE8VBASE85eI for <asrg@core3.amsl.com>; Fri, 10 Jul 2009 10:26:26 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id F04293A67AD for <asrg@irtf.org>; Fri, 10 Jul 2009 10:26:25 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id AE2CF33C7C; Fri, 10 Jul 2009 13:26:49 -0400 (EDT)
Date: Fri, 10 Jul 2009 13:26:49 -0400
From: John Leslie <john@jlc.net>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Message-ID: <20090710172649.GU15652@verdi>
References: <20090709173627.GP15652@verdi> <20090710004423.35119.qmail@simone.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090710004423.35119.qmail@simone.iecc.com>
User-Agent: Mutt/1.4.1i
Subject: Re: [Asrg] EPOSTAGE Too Big to Block?
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: Fri, 10 Jul 2009 17:26:31 -0000

John Levine <johnl@taugh.com> wrote:
> 
>>> The point is not the zombies attacking the crypto.  The point is
>>> zombies (ab)using their machines' legitimate owners' epostage.
>>
>>   This is a problem why?
> 
> It destroys epostage's credibility to potential users.

   Remember, the "users" are sending and receiving MTAs. I see little
benefit in defining a class of "potential users" that goes beyond the
class of current MTA operators.

   While I grant that FUD can always "destroy credibility", I don't see
it as hard to convince current MTA operators that if they give malware
access to a "bank" account they shouldn't be surprised when a particular
malware empties that account. "Credibility" of a cash-transfer system
running on compromised machines isn't a concept I wish to promote...

> Please see my white paper.

   Presumably John means

http://www.taugh.com/epostage.pdf

which makes a number of excellent points, most of which I quite agree
with. For example:
] 
] Since a sender can send the same valid stamp to many recipients, a
] recipient who gets a stamp from an unknown sender needs to check to
] see if it has already been used, by asking the issuing bank.
]...
] Most likely the majority of banks will be competently run, but some
] won't, deliberately or inadvertently issuing stamps that they can't
] later cash.
]...
] Usable international e-postage will need a system that lets recipients
] rapidly decide whether they're willing to accept stamps from unknown
] far-away banks.
]...
] If a stamp costs a penny... and 10% of the total stamps presented are
] real (the other 90% being spam), and that the bank's cut on each stamp
] is 10%, the bank has only 1/10 cent to spend to cancel each real stamp
] and 1/100 cent to reject a fake stamp.

   I believe draft-irtf-asrg-postage sets out to live within those
constraints.

   John continues and elaborates some threats
] 
] To send mail without paying postage, one might send spam with fake 
] stamps hoping recipients won't check them, send mail with forged
] return addresses that are on recipients' whitelists, send a little
] innocent mail to get recipients to whitelist them followed by a lot
] of spam, set up a fake bank that deliberately issues uncashable
] stamps, or trick a legitimate bank into issuing postage without
] paying for it.
] 
] To charge e-postage to third parties. one might sneak spam into other 
] people's mailing lists, or use a virus or Trojan horse software that 
] sends spam from the third party's computer.

   These are valid threats, but not in scope of draft-irtf-asrg-postage,
IMHO. They seem most appropriate for documents issued by "banks" to
their customers. I could go over any of them on request, but I see no
reason to try to address all of them in a single email.

   I expect to reissue draft-irtf-asrg-postage, and I am open to
suggestions for improvement, but issues such as those, IMHO, are better
treated in a draft on a possible implementaton of an ePostage bank (in
progress) or a draft on "best practices" for using an ePostage system
(which I'm willing to act as Editor for).

--
John Leslie <john@jlc.net>