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

[Chris Blask <blask () protegonetworks com>]

At 10:54 PM 2/5/2004 -0500, Rod Gilchrist wrote:
> On Thursday, February 5, 2004, at 07:28  PM, Chris Blask wrote:
.d.

Just to be clear:

o   Neither Rod (I know) nor I believe that any solution to Spam that 
removes the "ubiquitous access to freedom of speech" element of email is at 
all workable or desirable.  The points have been debated  in this context 
and I haven't heard a killer argument yet.

o  Also - I have no stake in the outcome more than any interested observer, 
and I don't think the solution to the problem will/should involve the 
monopolistic profits for any one company that is evident when capitalism 
goes wrong (Standards are the key!).

This does stray into the Application Firewall realm at least, but since 
it's kinda off-topic for the list I'll make my peace unless anyone wants to 
debate.  (I'll be happy to be proven right later... ;-)

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

It was (is?) a productive forum in many ways, I suppose I just bear some 
guilt that it'd couldn't have been made to do more.  The physics of momentum...

> 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

1) is the main point, imho.  My earlier comment about "boiling the ocean" 
refers to the resistance by the PKI community to focus on anything that is 
less than "protect me from the NSA" level technology.  That's not the focus 
that solves this problem, as Rod explains.

[Let's map the stuff we make to the real world - If you're some Joe 
Bagofdoughnuts out in the world and the NSA is studying the pimples on your 
asterisk using quantum computers, you have bigger problems than cert 
strength on your bloody email]

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

I've done my part.

Rod, subscribe.  I know you all have a lot of expertise to contribute.

-chris


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