Fwd: [Asrg] A New Plan for No Spam / Velocity Indicator

R. A. Hettinga rah at shipwright.com
Sat Apr 26 23:56:18 EDT 2003

--- begin forwarded text

Date: Sat, 26 Apr 2003 16:02:46 +0100
To: usual at espace.net
From: Fearghas McKay <fm at st-kilda.org>
Subject: Fwd: [Asrg] A New Plan for No Spam / Velocity Indicator
Sender: <usual at espace.net>
List-Subscribe: <mailto:usual-on at espace.net>

--- begin forwarded text

From: "Hallam-Baker, Phillip" <pbaker at verisign.com>
To: asrg at ietf.org
Subject: [Asrg] A New Plan for No Spam / Velocity Indicator
Sender: asrg-admin at ietf.org
X-BeenThere: asrg at ietf.org
X-Mailman-Version: 2.0.12
Date: Fri, 25 Apr 2003 13:58:06 -0700


	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).


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

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.

Asrg mailing list
Asrg at ietf.org

--- end forwarded text

--- end forwarded text

R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

More information about the cryptography mailing list