reminds me of the infamous "V-chip" and we all know how that one
turned out... while were at it why don't we all get verisign approved
smartchips implanted in our... "proprietary" is a four letter word
when it comes to this kind of thing. basically meaning bend over
while we beat exorbitant amounts of money out of all those worthy of
the ubiquitous verisign seal of approval? is this a plan for no spam,
or a plan to make lots of money for verisign? why sugar coat it?
All,
I finally got the revision of my paper 'A Plan for No Spam' through
legal and posted to the VeriSign Web Site. It is in PDF (sorry no HTML or
plaintext version).
http://www.verisign.com/resources/wp/spam/no_spam.pdf
I would draw folks attention to the Velocity Indicator described in the
Authentication section. This provides an overview of the trusted hardware
scheme I devised a few months back. While this is a proprietary technology
which we have applied for patent protection on and intend to enforce those
rights the scheme requires trusted hardware as a precondition and so the
license costs would fall on the harware vendor, not the software developer
so the patent would not be a bar to open source implementations (unless
there is a GNU CPU planned). This post does not waive the rights VeriSign
has to that technology, etc.
I will be publishing a fuller paper on the scheme in the large at a later
date. However here is a brief summary:
The trusted hardware base can be anything that is manufactured in controlled
conditions. It could be a palladium class PC, but it could equally be simply
a trusted bios, or a PDA feature, or it need not be a PC at all, it could be
a peripheral such as a smartcard or even a cable modem, nat box, anything
you like.
In the simplest version of the scheme a private key, a certificate and the
current time are loaded into the TCB during manufacture.
To create a message the client asks the TCB to provide an authenticator
token bound to the message in the usual fashion. This carries the 'velocity
indicator' as an authenticated attribute.
Each time a signature is created the velocity indicator is updated to
reflect the current rate of signing (you could also have a count of the
total signatures over the lifetime of the message). This could be the
signatures in the past hour and the past day (say).
When a recipient receives a message the velocity indicator and signature are
checked. The probability that a message is spam is low if BOTH the signature
binds to the specific delivery of the message to the user (i.e. has a valid
to: field) and the velocity indicated is low.
There are a couple of possible tweaks to protect anonymity. For example it
is not necessary that the signature be bound to a particular key. You could
use the key installed during manufacture to request new keys. You can even
partition the box so you have separate counts for different signers (this
could be appropriate for a bulk emailer box).
If someone takes a box apart and extracts a key we revoke it - not such a
big issue as you might think, the gaming studies we have done show that that
would be a very poor strategy for an attacker.
In essence what we have done is to reinvent the 'sender-pays' concept -
hence my previous arguments against handing over actual cash.
It is not necessary to have the expense of a transfer system with all the
excessive mechanism to prevent fraud that would entail. All that is
necessary is the scarcity property of money which we simulate in an entirely
scalable fashion. Unlike hashcash and the like this scheme is not vulnerable
to moore's law or assumptions of computational cost.
The one big drawback is that is does depend on replacing the hardware of the
Internet. This is not actually as big a deal as it sounds since it need not
be the PC, it could be a cable modem or a NAT box or even a dongle.
We could even sell/rent a box to an ISP that would be built on trusted
hardware that would sign all the emails going through their mail servers
with the velocity indicator being recorded on a per IP address basis. Bulk
mailers that send out mailing lists etc have to be dealt with differently
but they cannot conceal the fact they are generating large numbers of
emails.
There is also a layer to defend against certain obvious abuses and such but
I will describe those separately since they don't depend on the trusted
hardware. Here I have to untangle an issue that came up with the Borderware
people who have had similar ideas to some we came up with but I could not
talk about at the time.
Phill
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg