Re: Spam (or, how to buy Cheap Korean Cellphones :-)

[Rod Gilchrist <rod () borderware com>]

On Thursday, February 5, 2004, at 07:28  PM, Chris Blask wrote:

> > > Last year I worked (again) at BorderWare* and ended up chairing 
> > JamSpam
> > > (from which nothing but the AMY triangle has come out of afaik, to 
> > my
> > > chagrin).  BW's VP of Eng (Rod Gilchrist, infinitely bright guy) 
> > and I gave
> > > it serious thought and wrote a whitepaper for a structure dubbed 
> > "cmail"
> > > (certified mail) which as far as I can tell was entirely too 
> > straight
> > > forward to gain any traction <the reader will please manually 
> > subtract any
> > > battle-borne irony - I'm too tired to try>.

Cmail was a good shot and a year later it still seems to address all 
the issues.
(If you want to read the white paper, I can email it to you.)

Its primary problem I think is that the audience needs to get up to 
speed a bit
at a time and it is quite a big first bite. No point in solving secure 
opt-out in step
one.

(BTW, JamSpam was stunningly good at illuminating the spam problem
from all of email's participant's points of view. I think a lot of the 
conversations
happening between the big guys today started at those meetings.)



If you are going to start at the beginning and do things in tiny bites 
you need to
start with identity. People kind of 'get' that.

Then you need to add two tweaks....

        1) Relax identity far enough to make it practical
        2) Fix revocation

> > > If I recall, revocation lists were the best reason given for not 
> > trying,
> > > but at the end of the day SPAM has gotta be an identity fix, so may 
> > as well
> > > meet it head on.  I read this as yet another data supporting my 
> > belief that
> > > cert folks have trouble recognizing Users when they see them.
> >
> > Without revocation, the first Exchange overflow would break the entire
> > process.
>
> o  Revocation is necessary, but throwing up the collective PKS hands 
> isn't the way to address it.  Fix identity, fix spam.  A problem with 
> efforts to fix identity, imho, is that folks try to boil the damn 
> ocean when the task is to make a nice cup of tea,,,
>
> Cert folks:  Revocation is a problem?  Fix it!!  Don't make me come 
> down there and do it myself, I'll be so cross! ;-)

There are a couple of straight forward fixes for revocation.

You only get into deep trouble if you adopt the whole set of 
assumptions behind PKI. PKI is a
general solution that is intended to work over long (i.e. infinite) 
periods of time. Relax that set
of assumptions and revocation is solvable.

For email identity all you need is a key pair that's valid long enough 
for email to arrive at its
destination. A much easier problem than what PKI's revocation attempts 
to solve.


> > > Anyone else see - if in fact this is the right forum - any solution 
> > to spam that doesn't involve fixing the identity problem?
>
> There's the actual question for the list:  If it ain't ID, what *is* 
> the shape of the solution?

Yes identity is the first and most basic issue. But almost everyone 
gets hung up on perfect
identity as per PKI (i.e. individual identity right down to name, 
address and social insurance number).

You don't really need that at all to fix spam.

For spam its enough to be labeled as 'an AOL user whose mail mail is 
subject to AOL's terms of use that
require that the user never send more that 100 emails in an hour and 
that AOL has taken effective
action to enforce that behavior'.

From an email MTA's point of view that translates to 'a message that is 
signed by the mail source that
has public key 'X' and whose past behavior I see from reputation store 
'Y' rarely includes spamming
should be passed on without passing though my aggressive spam filter'.




So what's going to do spam in? I think a solution is coming. There are 
at least three separate solutions
out there that have relaxed identity into the practical realm; SMPTi, 
'Sender Permitted From' and 'Domain
Keys' (Google can fill in the details of all of these). The first two 
use IP addresses as identity,
which has serious limitations when messages are relayed (which is kind 
of basic in SMTP). Domain Keys
(from Yahoo) on the other hand is a home run.

With Domain Keys, the owner of a DNS domain generates a public/private 
key pair, signs all email
messages originating (via SMTP extension headers) in that domain with 
the private key and publishes
the public key via DNS. Since the publishing mechanism is out of band 
with respect to SMPT, no
changes are required to the SMPT protocol.

Details haven't been published yet, but revocation could be handled by 
publishing two public keys
via DNS (old and new) and a few days after the last email signed with 
the old key was sent, trashing
the old key.

So basically, Chris's grandmother doesn't need to get a certificate; 
her ISP worries about the key pair
and bounces all the email she sends that's addressed to all 115 of her 
grandchildren at the
same time. People publishing news letters need to be savvy enough to 
generate a public/private key
pair for their own mailer. And nobody pays Verisign...

If your private key gets stolen, your reputation (as measured by a 
DCC-like reputation server)
gets trashed and you need to make a new key pair and start building a 
reputation again.


So, we're winning I think. Much further ahead than last year.

- Rod



BTW, I'm not on this list. Hopefully Chris will relay as required.

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards