[PLUG] Spam, Etc.

[Ed Sawicki]

I agree that an obvious solution to the problem of spam
is to use a system that assigns keys/certificates
to people. This will probably not happen until there are
other reasons for assigning people certificates, such as
the national ID cards issue.

Until that happens, there are other less effective
solutions that are more effective than what we have now.
One way is to assign certificates to the machines that
move the mail. Sites that send spam will have their
certificate revoked. The problem with this is that
within hours the certificates of all MSN, Yahoo, etc.
servers will be revoked (which would delight me to no
end).

Another solution is to change the email architecture from
its absolutely flat structure to a hierarchy that establishes
"communities" that can communicate through gateways. A
community's gateway has rules for accepting mail messages.

Ed



On Sun, 2003-06-22 at 09:06, Jason Van Cleve wrote:
> My thanks for giving this some thought, Mr. Heinlein. . . .
> 
> On Sat, 21 Jun 2003 22:36:42 -0700 (PDT)
> Paul Heinlein <heinlein at attbi.com> wrote:
> 
> > No, it's law enforcement. It's one thing to identify and prosecute
> > people who commit crimes. It's a whole different thing to build a
> > preventative infrastructure to keep that crime from happening in the
> > first place. The bureacracy needed in the second instance is an order
> > of magnitude larger than that needed in the first.
> 
> Touche.  But then, you must agree, laws alone will not solve these
> problems.
> 
> > a. Keep a hard-copy record of which keys are registered with which 
> >    people and/or groups of people (corps, non-profits, government 
> >    agencies, softball leagues, etc).
> 
> Why the hard copy?  I didn't think DNS records had to be printed out, so
> why should these cert's?
> 
> >    This implies a 24x7 coverage whereby I could walk into an agency 
> >    office while on vacation in, oh, Montana, and report my key as 
> >    stolen. The staff there could *immediately* get a legal copy of my 
> >    original request and verify that I indeed have the signature and 
> >    other legal documents necessary to prove that I'm qualified to 
> >    revoke a key under my name.
> 
> That's a bitch.  Wouldn't having your driver licence with you suffice?
> Maybe a passphrase as well?  We prove our identities that way all the
> time.  If I can get on a commercial flight with just my licence, why
> should getting a new encryption key be any harder?
> 
> >    difficult to steal the cert verifying www.usbank.com. Stealing the 
> >    certs of the non-tech-savvy people you want to protect is a 
> >    relative piece of cake.
> 
> Probably.  I guess the thief would have to break into (or actually
> steal) my computer and find my private key (and decrypt that if
> necessary).  But the real question here is, would stolen cert's be so
> ubiquitous that spammers could use them and still remain untraceable?
> 
> > c. Have a near-instantaneous way to propogate or revoke a key.
> 
> Maybe, maybe not, but good point.  If using email depended on the cert',
> and the cert' would become invalid immediately when abused, then you're
> right.  One workaround would be for people to keep a backup cert' for
> that contingency, maybe one they only keep on a diskette or hard copy,
> hidden in the attic.  A bit of a hassle, but generally only a one time
> thing.  But this way, we wouldn't really need right-away new-key
> service.
> 
> >    interest on consumer debt. I laugh at the chance that you'd be able
> >    to rally public support for a tax or fee structure that could 
> >    generate even a small percentage of that level of funding.
> 
> Easy now, I never said I was an expert on this stuff.
> 
> > d. Have a process in place whereby keys are expired regularly.
> 
> I don't understand the need for this.  My driver licence lasts four
> years.  Is four years what you mean?  Keys would be expired when they
> are used illegally.  Beyond that, like email addresses, why expire them
> at all?
> 
> > e. Have procedures in place to reduce the likelihood that a rogue 
> >    employee or group of employees could defraud the process.
> 
> True, but this is not a show-stopper.  Many systems have this problem.
> 
> > g. Maintain said distributed server farm with a near impeccible 
> >    security record. Trust would be everything in this situation. The 
> >    costs would include physical security, electronic security, and a 
> >    well trained (and therefore probably well paid) set of network and 
> >    system administrators.
> 
> My proprosed system is not as mission-critical as you think.  When I
> wrote "no biggie", I had in mind that if an ID server went down, it
> would not disable any email servers.  Emails would still go through,
> probably tagged as "could-not-validate".  So for a brief window of time,
> spam could sent from any unidentified source.  But you'd still get your
> business email.
> 
> >    Oh, and those admins would have to devise a system so that keys 
> >    couldn't be harvested in the same way that e-mail addresses are 
> >    now. I mean, if the keys are publicly available, what's to stop a 
> >    spammer from just harvesting the keys?
> 
> Once again, this is a public key system, so the important part, the
> private key, wouldn't be published anywhere.  It wouldn't have to go on
> the ID servers, and it wouldn't even have to go to the controlling
> agency.  It would stay at home and be used to sign outgoing email.  Or
> is my understanding of public key cryptography all messed up?  Having a
> record containing only the public key component to identify each entity,
> the server could look at a signed email and verify that the sender
> indeed possessed the private key for the given public one.  That is
> correct, is it not?
> 
> > So you're a contractor, and your bid doesn't get to your potential 
> > client in time because the identity server is down. Is it still 'no 
> > biggie'?
> 
> See above.
> 
> > The cost of maintaining a public electronic identity-verification
> > system would be huge. The thing is, regardless of whether the system
> 
> Counterpoint:  the cost of dealing with spam is huge, not only in terms
> of money, but in terms of cultural (and political) stress.
> 
> Perhaps my elusive "scale" will only come in the form of a complete cost
> analysis.  At this point, I'm just trying to establish whether it would
> work technically.
> 
> --Jason Van Cleve
> 
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
-- 
Ed Sawicki <ed at alcpress.com>
ALC