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(_dot_)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(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg