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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 25 Apr 2003 13:58:06 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: matthew richards <[email-masked]>
Date: Fri, 25 Apr 2003 14:49:35 -0700

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?

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 25 Apr 2003 17:15:46 -0600 (MDT)

> From: matthew richards <[email-masked]>

> ...

I think that unfairly characterizes the idea described in the preceding
message.  I don't think the idea is intended as a way to save Verisign.
The comparison with the television V-chip is also misplaced, but in
the sense that the V-chip did have some hope if you suspended disbelief
about likely actions of television viewers.  It's one thing to expect
a few dozen to several hundred (depending on how you count them) old
fashioned broadcasters, cable TV system operators, satellite TV operators,
and television receiver vendors to support the V-chip, particularly
when they are all licensed in one way or another by the U.S. FCC.  It's
something else to hope for legitimate mail from its current 500,000,000
sources to be authenticated using new hardware or software.

Authentication as a spam solution suffers from many fatal problems,
including the V-chip failing of expecting TV viewers to require ratings
or authentication and the obverse of requiring millions of senders to
authenticate their mail.  For example, how was the announcement of the
new version of http://www.verisign.com/resources/wp/spam/no_spam.pdf
authenticated?  I think it did not use S/MIME, PGP, or STARTTLS,
at least not as it reached my MTA.

In two light readings of the document, I failed to find any explicit
references to Verisign anti-spam authentication.  That may be my error,
or perhaps it will be discussed in a future document.

Relatively minor, easily seen problems in the current document are
  - A definition of the spam problem based on 89 messages received by
   one person is less than convincing.  Several times that many messages
   every day in my filters and traps have convinced me that you need
   many thousands of samples drawn from many targets to say much.

  - The section about blacklists in the document describes actions by
   minor blacklists such as attempted extortion as if they were
   representative.  They are not.

  - On page 10, the document mischaracterizes NNTP as using a "pull model."

  - Page 13 seems to mischaracterizes the DCD as using 'honey-pots' or
   other automated or manual spam sampling techniques and "fingerprints"
   of "known spam messages."  That is not what the DCC is about.

  - Page 23 seems to deny the existence of SIEVE.

There are other, more complicated errors in the document, such as
its discussion of legislation and foreign sources of spam.

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: wayne <[email-masked]>
Date: 26 Apr 2003 19:21:52 -0500

> http://www.verisign.com/resources/wp/spam/no_spam.pdf

Vernon and others have pointed out other errors/problems that I agree
with, including the mis-characterization of DNSBLs.  However, I will
elaborate on the problems with your discussions of DNSBLs.

First, you inaccurately use inflammatory words to describe DNSBLs.
For example, instead of using the term "vigilante" to mean "taking the
law into your own hands", you define "vigilante" as being
"unaccountable".  Since there are very few laws in the area of spam,
it is hard to claim that anyone is taking the law into their own
hands.  Moreover, vigilantism generally has the connotation of a mob
force.  You claim that DNSBLs are being coercive ("*forcing* to act or
think in a certain way"), and as a censor ("some sort of
official/authority that defines objectionable material").

DNSBLs can not force anyone to do anything and any authority given to
them is by consensual users of the DNSBL.  DNSBLs are opinions about
the standards of conduct of email coming from certain IP addresses and
domains.  DNSBLs are no more coercive than requiring the sending MTA
to connect at the right port (25), send syntactically valid SMTP
commands, provide a return path that can be resolved, having
sufficiently few "spammy" type keywords in the email body, have a
sufficiently low Velocity Indicator, have an e-stamp, etc.

All of the above requires are standards of conduct set by the
receiving MTA in order for email from the sending MTA to be accepted.
All can create false positives, all have secondary effects and all can
be abused.

Secondly, as Vernon points out, "the section about blacklists in the
document describes actions by minor blacklists such as attempted
extortion as if they were representative.  They are not."

Your statement that "Blacklists can only work as long as the Internet
community generally can have confidence in the way they are run." is
exactly right.  Their widespread use indicates that many receivers of
email have confidence in at least some DNSBLs.  Yes, senders of email
may not agree, but email senders can no more "force" receivers to
accept their email than receivers can "force" senders to conform to a
standard of conduct.  When senders and receivers don't agree, they
don't transfer email.  

You claim that "Unfortunately the majority of blacklist operators
appear to consider themselves beyond accountability."  DNSBL operators
do not *NEED* to be accountable to anyone other than people who use
them, and those people can freely choose to stop using a DNSBL if they
want.

You claim that "None of the blacklist maintainers describe a dispute
resolution procedure; most do not even provide a contact address."
This is certainly not true for most of the major blacklists, the only
exception that I can find is SPEWs.  The following are the DNSBLs that
I use in one form or another: ORDB, DSBL, SBL, relays.osirusoft, RFCI,
bondedsender, OPM, NJABL, SpamCop and habeas (HIL and violators).
They all publish removal procedures and contact addresses.

You claim that "In one recent incident one of the blacklists listed
the entire nation of China. Another blacklist listed UUNET, one of the
largest ISPs in the US including all its customers in an attempt to
force UUNET to shut down a Website run by a UUNET customer."  You have
made these claims before, but you have never documented them in any
way.  There are certainly DNSBLs that block all of china (and many
other regions of the world, for that matter), but the only ones I know
are very explicit about what they are doing.  For example,
cn-kr.blackholes.us is clearly a DNSBL that blocks both China and
Korea.  Without some documentation, you are just spreading FUD about
DNSBLs.

Thirdly, in the "BEST PRACTICES" section, you talk about creating some
sort of "common agreement on best practices for blacklists setting out
criteria for issues such as notice to the listed parties, appeals
processes and the acceptability of `collateral damage'."  This is both
unnecessary and undesirable.

It is unnecessarey because DNSBLs can not force anyone to do anything,
their only authority comes from others who freely choose to use them.
Any DNSBL that does not do a good enough job of either spelling out
what standards of conduct are required to not be listed, or do not
adhere to the standards they claim to certify will probably not be
widely used.

It is undesirable since different organizations have different
priorities about what standards of conduct they want to require for
senders of email, you *want* a wide variety of DNSBLs.

Finally, you include DNSBLs as part of your overall spam solution.
You say that it is better to use them as one factor in the filtering,
rather than a straight accept/deny system, and I can agree with that.
However, that choice is really up to the organization receiving email
to decide.  I find it very strange that you would spread so much FUD
about DNSBLs and then turn around and say that they are part of the
solution.

-wayne