On Wed, Dec 3, 2008 at 8:33 AM, Bart Schaefer
<schaefer(_at_)brasslantern(_dot_)com>wrote:
On Dec 3, 12:08pm, John Levine wrote:
} I think it's reasonable to assume that bad guys will be able to crack
} any software based meter. (An obvious attack is to snapshot the newly
} installed meter and restore the snapshot whenever it runs out of
} money.) Are you expecting meters to include tamper resistant hardware?
[...]
All the sender does is present his identity. The recipient's postage
meter issues a stamp which is only good for sending one message to that
recipient. The sender's "coin" has to come from a bank trusted by the
recipient [...]
The sender's identity doesn't even have to be authenticated, because the
bank has a trusted relationship with the recipient and the recipient can
be authenticated.
Very nicely stated. The risk and reward of how well the recipient's meter
works belongs solely to the recipient. The "cost" of "coin" is implicitly
determined by the recipient in his choice of trusted "banks".
Yes, all of this takes a lot of setup that doesn't happen now. There are
still a whole variety of questions about whether it's viable to create
such a system. But can we please stop arguing from the assumption that
senders can arbitrarily print and re-use one stamp for many recipients?
Thank you. And can we accept that the technical aspects of coin/stamp
exchange
as part of SMTP are segregable from the technical aspects of secure coinage?
ePostage coin doesn't "have" to be based on micropayments, there might
be "banks" that issue coin based on corporate identity, TLD registration,
DNSBL status, transfer of iTunes credits or sender bonding. The recipient
chooses which banks to trust, and the system of payment between sender and
recipient is thus independent of whether or not an electronic proof of
intent ("coin")
can be exchanged between two unknown parties over an unsecure medium.
I think the question boils down to whether a recipient and sender can
"handshake" on a trusted 3rd party ("bank"). Not a central bank, but one
out of all such banks where they both have accounts. The transaction
within the bank is separate from the transaction in SMTP that exchanged
the "coin".
Personally, I believe that the "stamp" exchange that Bart described
can be done via HTTPS prior to an SMTP connection and the retrieved
"stamp" is used to verify a "coin" exchange from any sender.
The sender is "verified" by the redeeming "bank" according to their
standards.
I really don't care to argue whether "coin" should cost 1 cent or
5 cents or whether "wanted" mail should be free, or some quota should
be "free". I think it's analogous to how individual DNSBL's choose to
list and unlist IP's (versus the DNS software that they run on). The
question of what rules I want applied for my inbox are implicit in which
DNSBL's I configure in my MTA/MUA. Similarly, I think all of the questions
related to value and reliability of "coin" should be determined by a
recipient's choice to accept "coin" issued by various "banks".
For all of the discussion about ePostage, I only see arguments against
security of banks and coins and what is viewed as acceptable value.
I haven't seen anything that makes me conclude that a single "coin"
transaction between unknown recipient and sender is impossible.
Gerald
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg