Re: [Asrg] Too Big to Block?

[John Leslie <[e-mail]>]

der Mouse <[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?
> 
> Because it means epostage won't help: it'll just mean that abused
> machines' owners pay in yet another way.

   In the ePostage draft I'm looking for a round-tuit to update, tokens
are issued only to "bank" customers, and only on request. If some home
user actually sets up such an account, he shouldn't be surprised when
that account gets used. (If he chose to put it at risk for more than, say
$10, then the bank deserves any hassle they get for not explaining the
risk more thoroghly.)

   In practice, I expect home-user accounts to be rare, and most users
to send through an ISP or corporate MTA. Those folks won't be surprised
more than once!

> (If epostage is expensive enough, it may help a little in that it may
> slightly reduce the compromise rate,

   Although I don't expect that whole path to be much used, _any_ cash
penalty will tend to get someone's attention!

> but I think more likely it will result in pressure against epostage.)

   What means "pressure against ePostage"? If you mean simply refusing
to pay any under any circumstances, so what?

>>>> Making ePostage work is clearly possible in an environment of [...]
>>> Quite possibly.  Are such environments common enough to matter?
>> I can imagine them... Why couldn't they be common?
> 
> I don't know.  But deployed epostage seems to be remarkably rare, so
> _something_ is preventing its uptake;

   Uptake must _follow_ actual deployment. My belief is that every
deployment which could be classified as ePostage so far has been too
expensive, and has created some incentives which are plain _wrong_.

   (It would help _me_ if folks pointed out where draft-irtf-asrg-postage
creates "wrong" incentives.)

> either your idea of how common such environments are is way high or
> there's something else preventing deployment despite what appears to be
> an open-and-shut case in favour.

   I didn't claim "such environments" are common. Remember, I specified
- short token lifetime,
- encryption of paths it travels, and
- sufficient logging of failure-to-redeem to support (automated)
  investigations of fraud.

   Have I missed other ePostage proposals that included all of these?

--
John Leslie <[e-mail]>