On Fri, 21 Mar 2003 20:55:15 +0000, Adam Back <adam(_at_)cypherspace(_dot_)org>
writes:
On Fri, Mar 21, 2003 at 02:28:31PM -0600, Scott A Crosby wrote:
On Fri, 21 Mar 2003 19:46:08 +0000, Adam Back
<adam(_at_)cypherspace(_dot_)org> writes:
The Stamps discussion seems to be reinventing hashcash (are some not
aware of hashcash, or is there some aspect of the Stamps discussion
different from hashcash in some way I am not seeing?)
Yes, it is strongly inspired by HashCash, but it is different. The
differences is that HashCash is only used for initial communication.
This is an optimization also proposed for hashcash when one gets down
See below, but I believe that this is a necessity, not an
optimization; for hashcash to be expensive enough that spammers cannot
afford to burn the cycles, email hosts cannot afford to burn the
cycles, and legitimate end-users will go bonkers from 10-120 minute
latencies.
to "so how would you deploy this" question. See for example the
I think what is needed is to pragmatically answer the deployment
questions. IE, rather than offer possible design choices/ideas for
deployment, bite the bullet and choose the best set of design choices
and document them.
CAMRAM architecture:
http://www.camram.org
How does CAMRAM deal with mailing lists. Are you using the signature
stamp, but won't that force a mailing list programs to incur
relatively expensive public key operations. Or are 'expensive public
key operations' not really considered that expensive anymore? Doing
some benchmarking, I find that my P2-450 can sign&verify about 50
messages/second. What is a 'high' email load for a P2-450 running a
high-volume mailing list? Is it under 10 messages/second?
In particular I proposed such a token would be a MAC computed using a
secret key held by the user. Then he could verify it without storage,
based just on the sender address and the token. Having expiry could
I think that using the sender's email address in any token is a design
mistake. The sender's address is forgable, so the security gained over
a plain token is relatively small. If 'they' can find the token, they
can probably find out the from address to forge. Second, many people
have systems that depend upon forgery in order to direct incoming
email where they wish.
I also am reluctant to use signatures on emails because emails get
massaged and altered between my client and your client. From robots
that add on disclaimer notices, to antivirus software to spam/bulk
classification software to mailing list software, messages are
constantly altered. How does one figure out what is and isn't safe to
MAC? I've had a pet theory that email signatures might finally work if
we redid the email spec such that a message (headers and body) was
actually implemented as a versioned archive like RCS. That way, I
could sign the first version, and each host along the email chain
would make any modifications and check in a new version.
be optional feature, but there is limited need given the storage-less
aspect. Tokens could be revoked by putting them in a recipient local
black-list.
CAMRAM settled on using signatures for the tokens in place of a
MAC-based token but it's effectively the same idea I think.
I think so too, the major differences are that the token is a lot
larger and a lot more expensive to verify. I do not know if these
considerations are relevant in practice anymore.
An additional idea previously proposed was that reducing the use of
hashcash tokens to first unsolicited email could perhaps be used
instead of increasing practical hashcash cost, could be used to deploy
hashcash token creation into the senders sending mail hub. This would
then remove the need for a hashcash aware client. The downside is it
increases sending MTA load, but the deployment problem is easier for
MTAs than for clients.
It depends upon the hashcash token minting cost. I'm envisioning 10
ghz*minutes or so, where I don't think this is practical. If the
minting cost is on the order of 1*ghz second, I don't think its
hashcash will alter anything at all.
A shiny new 3ghz system amortized at $1000/year over 3 years amortizes
to $3/day, and is good for 300,000 ghz seconds/day. At a 1ghz*second
of minting cost, the amortized cost per message is 100,000/$1. The
spamvertizing costs are $100 buys a million? Thats $.0001/message, or
ten times the costs to the spammer from minting. Even a minting cost
of 60 ghz*seconds would only increase the cost to $600/million. Worse,
Moore's law will eat into these costs by a factor of 8 over the next 5
years.
Thus, I think we'd need on the order of *AT LEAST* 10 ghz*minutes of
hashcash to make spamming unaffordable, and perhaps 100 ghz minutes 5
years down the line. IMO, would 10 ghz*minutes of CPU to mint just one
stamp makes it impractical to expect a mail gateway to mint hashcash
style stamps?
You know what the quote goes? ''A protocol is not done when there is
nothing more to add, but when there is nothing more to take away''
Well, I'm taking it to heart when I ruthlessly simplify your
system. :)
Scott
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg