Subject: [Asrg] Hashstamp-like proposal

From: [email-masked]
Date: Mon, 24 Mar 2003 03:31:25 -0600

For those of you who have tossed around the idea of a hash-stamp or other 
type of stamping protocol, I implore you to check out this proposal.  I 
believe it to be very close to a workable solution, if not one, for 
limiting any type of undesired network communication, but specifically 
eliminating SPAM E-Mail.  I know I've thrown this idea out once before but 
I only received a few responses from people who completely read the 
proposal and understood it's workings.  A web page has been put up 
explaining the idea at http://meor.xwarzone.com/overview.htm  For those of 
you that have read it before, a few paragraphs have been added to the 
beginning of the proposal to more properly introduce the concept and make 
it easier to follow.

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

---

From: "Jon Kyme" <[email-masked]>
Date: Mon, 24 Mar 2003 10:01:40 +0000

> beginning of the proposal to more properly introduce the concept and make

DRAWBACKS OF THIS METHOD

1. Requires a new client, server, and protocol in order to be implemented.

Is that all? :-)

--

---

From: David Finnie <[email-masked]>
Date: Mon, 24 Mar 2003 22:19:31 +1100

> beginning of the proposal to more properly introduce the concept and make 

I see several potential problems with this method - most importantly
(see below), that I think it can be circumvented by spammers:

- it is patented. Admittedly a free licence is granted for free
  software, but it is fairly clear that's not the case for "for sale"
  software.

- the last time I checked, DSA is patented. I don't know what the
  situation is at the moment re. licensing DSA technologies.

- it doesn't actually "eliminate" spam - spammers may still choose to
  wear the cost of computation. From my reading of the protocol, after
  they succeed in cracking the weak cypher key, the spam message is
  still delivered. That's different to my definition of "eliminate".

- a distribution list could be the way spammers get around this protocol:

  spammer joins ASRG list, starts collecting names

  since ASRG mail server is sending messages to us, it includes its
  public key and a signed piece of info in every message. 

  spammer gathers 1 or more of these signed pieces of info, and send a
  message to the recipients of the list, using the ASRG mail server's
  public key and signed piece of info. Since all of us have (of
  course) included ASRG in our white list, the spammers messages get
  through with no challenge/computation effort.

  Have I missed something ?

Dave

---

From: [email-masked]
Date: Mon, 24 Mar 2003 12:10:35 -0600

>1. Requires a new client, server, and protocol in order to be implemented.
I see what you're getting at.  Unfortunately as far as I know there hasn't 
been a good solution presented that doesn't either break SMTP or require a 
consensus among all clients and servers; which in effect is a new protocol.

---

From: [email-masked]
Date: Mon, 24 Mar 2003 12:22:04 -0600

>   situation is at the moment re. licensing DSA technologies.

If there is an issue with the DSA licensing scheme, I believe this method 
could use any digital signing method in order to get the desired effect.

>   still delivered. That's different to my definition of "eliminate".

Well, what this method does, is make it infeasible to make a business out 
of spamming.  When you require connections to identify themselves it 
becomes very easy to make it very hard for a select group of people to 
abuse it.  For instance if a big company emerged and used the domain 
spammers.org or certain IPs that were known, E-Mail host operators could 
easily make it 10 time or 100 times more difficult for a message to be sent 
from that domain or group of IPs.  Knowing that it is so easy for an E-Mail 
host admin to single them out and ramp up difficulty in sending, spammers 
would be very weary of investing a large amount of money in getting more 
processing power.

The difficulty alone in solving the computation task makes it impossible 
for a single CPU or group of them to be effective at spamming.  If mail 
host administrators generally picked a 10-20 second work load for a message 
to be sent, that would mean 10-20 seconds between each message which would 
be a huge detrement to spamming.

>   Have I missed something ?

Well, that is a good idea however I think this "problem" would be solved 
with a good implementation.  If the mail host generated a random message 
and required the client to sign it, there would be no way for a client to 
know what information it would be required to sign and no way for other 
clients to use them.
Second of all, the signed piece of information isn't distributed.  Once 
identity is verified the information is discarded so the only way for a 
spammer to gather signed information would be to be a mail host.  Aside 
from the fact that gathering signed information has no benefit.

---

From: Brad Templeton <[email-masked]>
Date: Mon, 24 Mar 2003 12:11:52 -0800

> beginning of the proposal to more properly introduce the concept and make 

Doesn't seem to be anything new in this system or anything that solves the
major problems of such systems.

In fact, it seems to miss out on the goal of being able to pre-stamp a
message before you send it to a stranger, rather than needing a 
challenge/response protocol on top of the test, which has a number of pitfalls.

On top of this, this system seems to be expecting some sort of PKI to be
in place for authentication.   Or if there is no PKI, I presume it's of the
"First person to declare a key for address X sets the key" form.  While such
schemes have their merits, they are not without some significant flaws, including
the famous nasty denial of service attack (and now you have people motivated
agains the system, unlike mail encryptors, so DoS is a serious worry) and
the problem of people who lose their keys.

In general, while I was the first person in the community I know of to advocate
stamp systems, I now disavow them.  A variety of the reasons are outlined
at www.templetons.com/brad/spume/estamps.html at the bottom.

I do agree that cpu-stamps are superior to money based stamps for a number
of reasons, but this system doesn't seem to do enough to take advantage
of those superiorities.

If you want to do a CPU stamp system and have any chance of its adoption,
what you need is the following:

    When the system decides to reject mail from an unknown due to lack of
    stamp, the "postage-due" notice should contain a URL to a java applet,
    the URL containing full parameters to identify the message.

    The message should be held in a spool.

    The applet should calculate the response to the hard-problem.  Since
    the JVM is probably slow at this, a problem thought of as a 4 second
    problem might well be a 40 second problem, however...

    The applet should do its calculation in the background, in a window
    that is iconized.  It should pause frequently so that it does not
    saturate the CPU of the user.  Thus it might take even minutes to solve
    the problem.

    However, when the applet is done, it returns the calculated value to
    the server from which it was downloaded, and then silently terminates.
    The user does not have to be aware of this.

    The server receives the calculation result and forwards it to the mail
    system that issued the postage-due.  The mail system checks the
    result, and if it is OK, fetches the held mail from the spool and
    delivers it.   If not, it can be deleted or moved to another queue etc.

This is the standard of ease of use that a stamp system has to live up to.
Simply click on a link and forget about it, and your mail will be delivered.

However, even this has flaws:
    a) It requires a JVM (or other fast portable executable platform.  CLR could
       also be a choice.)
    b) It can't be done offline

And it has many of the other flaws of e-stamp systems.   Mailing lists remain
a perpetual problem.  For one, it would be a violation of the standard to
send any challenge to mailing list mail, ie. that which is tagged with a
Precendence: bulk header.

I believe the best solution must permit a global whitelisting of legitimate
mailing list operators, though it can be done through a number of means.
In a way, Habeus is a very basic form of that.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Brad Templeton <[email-masked]>
Date: Mon, 24 Mar 2003 12:24:39 -0800

> consensus among all clients and servers; which in effect is a new protocol.

Do you mean a good solution involving e-stamps, or in general?  e-stamp
solutions are normally predicated on having new software at both ends,
which is a nearly insumrmountable problem.  It would take a very compelling
case and design to want to do this, and the switch would need to be gradual.

However, there are non-stamp solutions, or solutions which incorporate stamps
as simply one possible way to verify accountability for abuse in an E-mail
which can make use of them.

You need to minimize the number of parties who have to change software.
Recipients of mail are, however, highly motivated to install software to
rid themselves of spam, and sysadmins of MTAs that receive mail are similarly
motivated.

However, anything that requires new software for ordinary senders of mail
seems a non-starter.

Something that requires new software for senders of bulk mail is within the
realm of workability, and since bulk mail is where all the issues like, this
makes sense as the place of minimum damage.   Depending on what volume levels
you define as bulk, the number of people hosting large mailing lists is
manageable, and they as well are incented to get new software it it is
necessary to get their list through.

However, even so, we must consider there are very large numbers of small time
senders of small bulk mail, namely ordinary individuals who send out things
like party invitations, birth announcements and the like to all of their
friends and associates.   They should not be required to get new software.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: David Finnie <[email-masked]>
Date: Tue, 25 Mar 2003 12:35:50 +1100

> could use any digital signing method in order to get the desired effect.

Agreed. The RSA patent has expired, so I would guess it is a better
solution (all other aspects of this solution ignored).

> be a huge detrement to spamming.

Yes, I understand the concept. However, I would imagine that even if
every single email person in the world adopted this approach, there
needs to be a way for users who know each other to distrubute keys to
each other. That would certainly be the case for a person signing up
to email for the very first time. The obvious way to distribute this
is to send an email with their PKI public key attached, and to do
this, they would need to resort to the challenge response protocol. So
the challenge response protocol could never be too constraining,
because people's first experience of email would be attrocious. Given
that, I think that spammers who thought they had a very valuable
product may still choose wear the CPU costs of going through the
challenge response protocol.

> know what information it would be required to sign and no way for other 

I'm a litte confused by what you are saying here. From my reading of
http://meor.xwarzone.com/overview.htm, it doesn't mention anything at
all about the mail host generating a random message for signing. Here
is the quote from the description:

"When a sender wishes to send a piece of E-Mail to a mail host, it
begins communications to the mail host by sending its public key and a
signed piece of information to the mail host for verification.  The
mail host first checks to see if the public key is on the authorized
white list of the end users mailbox.  If the public key is authorized
by the mailbox, the mail host then verifies the signed piece of
information with the public key to see if the information was
correctly signed.  If it had been correctly signed, the mail host
allows the sender to send its message to the mailbox."

Note that there are some omissions from this text. Primarily, what is
the piece of info that the sender is signing, and how does the sender
get it? I was assuming that because this is an unsoliciting email by
the sender, it has not (necessarily) had any prior communication with
the mail host, and therefore invents its own info to sign. It would
also need to send this info along with the signed version of it.

Are you saying that when the sender uses a public key/signed info
method of connecting that there is some prior communication with the
[recipient] mail host whereby the mail host provides the data to sign
? If that's the case, then that is a vital piece of information
missing from the protocol description.

> from the fact that gathering signed information has no benefit.

I think this goes back to the method for choosing data to sign. If it
is on a per-recipient basis, and decided by the recipient mail host,
then yes I agree with you. However, that is not stated in the protocol.

David Finnie