Re: [Asrg] EPOSTAGE Too Big to Block?

[John Leslie <[e-mail]>]

John Levine <[e-mail]> 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 <[e-mail]>