Re: [Asrg] About that e-postage draft [POSTAGE]

[Benjamin April <ben at stagecraft.net>]

Steve Atkins wrote:
>
> On Feb 16, 2009, at 7:07 AM, mathew wrote:
>
>> On Sun, Feb 15, 2009 at 17:12, John Levine <johnl at taugh.com> wrote:
>> >> It is possible to defend against this threat, but not cheaply, since
>> >> the defense requires a robust transaction system that can serialize
>> >> the thousand requests, approve one, and reject the other 999, while
>> >> still providing service to the rest of their customers.
>>
>> >Nonsense. You just make the purchased stamp dependent upon the
>> address of
>> >the recipient, for example by hashing the To: address inside the
>> >cryptographic stamp when it's minted.
>>
>> Aw, come on.  Please don't tell me I have to explain why this model has
>> the exact same problem.
>>
>> Go on, indulge us. Explain why stamps that are hashed to the
>> recipient can still be spent on multiple spams unless a network
>> transaction is carried out for every one.
>>
>> Let's go ahead and assume that the stamp also has an expiry date
>> encoded into it, mmkay?
>>
>
> If it's simply hashed then anyone can create them. That means it's
> possible to send a large number
> of messages using stamps that look entirely plausible prior to them
> being looked up at the central
> broker. There are obvious reasons why people would do this.
KISS, A simple back-off solves this. After your third bogus token my MTA
won't accept a postage-due e-mail for 1 minute from your MTA. IMO
something like this should be done regardless of weather the token has
any encoded meaning. (insert your own values)
> So, the next step is to use some crypto such that it's possible for
> anyone to validate that the stamp
> may be plausible for the recipient, but not for anyone to generate it.
> Maybe you use public key
> signatures - presumably with the private key held solely by the bank.
My main concern here is that allowing the receiving MTA to validate the
token offers a false sense of authority. We now know it is far easier
than originally expected to create a "fake" signing cert. While some
will argue that using appropriately modern hashing etc will mitigate
that, I say it only delays the inevitable.
On the other had the only known valid attack against a truly random (and
secret) opaque token is brute-force.  We have plenty of history to look
at for reducing the effectiveness of this kind of attack.
> But that means that stamps are not interchangeable. You can't buy them
> or generate them in
> advance, or at least not in bulk, in advance. Instead you have to
> purchase them (from one of a
> small number of "banks") at the time you send the mail as well as
> redeem them (from that very
> same bank) later.
I see this as a big issue.  I would find having to go to the post office
every time I needed a stamp insane. By using opaque tokens you could buy
a selection of tokens in advance and dispense them on demand.
>
> (Given that the sending machine has to contact a central server and
> the receiving machine
> also has to contact the same central server during the transmission of
> the message there are a lot
> of other things you could do with it that are simpler than epostage).
In the opaque token model I do not see this as a required state.  You
would be able to pre-buy tokens and only the recipient would have to
have ongoing connection with the "BANK". Maybe some banks will offer
discounted fees to MTAs who provide advance notice before placing a big
order for tokens.

Thanks
Ben
>
> Cheers,
>   Steve
>
> _______________________________________________
> Asrg mailing list
> Asrg at irtf.org
> http://www.irtf.org/mailman/listinfo/asrg