Re: [9fans] re: spam filtering fs

[Dan Cross <cross@math.psu.edu>]

David Presotto <presotto@closedmind.org> writes:
> You're going to have to derive a canonical form of the message
> so that you have something to sha1 that won't change as it
> traverses the network.  Not hard, just need a definition.
> Something that includes the important headers (From:,
> Sender:, Reply-to:) and the body would be enough.  You
> might want to worry about making cr-lf == lf.

That's easy enough. Btw- it thinking about it highlights a hole
in my idea of the nonce/hmac of nonce method: it's vulnerable to
replay attacks, unless you keep a log of nonce's.

> Then you need a way to add the signature.  I'm happy with an
> S/MIME attachment but some people here hate S/MIME.

An RFC822 header would be both easier and, I think, more efficient.

> Then you need a database of shared keys.  If it were public
> key encryption, you could put the public half on a shared
> server but since these are secrets, we have to keep them to
> ourselves somewhere.

Here it comes down to only expending effort approriate to the value
of the information being defended.  This isn't meant to be a mechanism
for ensuring the absolute integrity of the message; it's meant to cut
down and try to eliminate spam.  Appending an HMAC to a message
someplace is a low cost way to do that.  How you choose to store the
keys you use for that hmac is up to you.  Putting them in a file in
your home directory should be enough; it should be understood up
front that this isn't a mechanism for fool-proof identification of
the sender.

> Finally, you need a way to introduce yourself to someone and
> give them a token.  This is always the hard part.  PGP sort
> of solves it with trusted places to leave the public key
> and by passing notes that are fingerprints of the public keys.
> Of course, the easier you make this, the easier it is for the
> spammers to insert themselves.

Again, it doesn't have to be foolproof.  What it *does* have to do
is raise the bar enough to defeat the automated address harvesters.
A simple way to transfer tokens is to send someone an image (or a
pointer to one) that depicts a string (maybe a sentence of diceware
words or something) and use that as the secret.  A human being has
to look at the image to figure out what the string is, which is going
to *drastically* cut down on the ability of machines to harvest
addresses for spamming (at least until image recognition software
gets more sophisticated).  I don't care if the guy sitting next to
me sees it, as long as he's not a spammer.

> Anyways, by the time you're done, you've defined PGP.  Why not
> use PGP?  If you're trying to be simple, you don't need their
> encryption (which hardly anyone uses anyways) or their complicated
> rules for trust relationships.  Then you have exactly what
> you're asking for and you stay compatible with some part of
> the world.

PGP solves the problem at the wrong level.  Here, one can attempt to
solve it at the SMTP transaction level.  With PGP, that's possible, but
more cumbersome; it's really set up for users to do authenticate each
other.  What's more, I still contend that even PGP has a much higher
`startup cost' than a simple HMAC using a shared secret, where sharing
the secret isn't really that important, and it's unnecessary to keep it
absolutely secure.

Besides, using PGP for this is like cutting butter with a chainsaw.  I
want something simple and lightweight.  Since this *can* be really
lightweight, getting vendors to incorporate it might be easier; PGP has
been around for 20 years, and it's still not a part of most MUA's.  Why
is that?  Even TLS has found it's way into outlook; why not PGP?  Are
there commercial restrictions?  Is it just too complex?  Given that
it's not universal, what part of the world am I becoming incompatible
with?  S/MIME is similar: comparatively speaking, nobody uses it.  I
shouldn't need to write an ASN.1 compiler to put the base64 encoding of
an HMAC in an RFC822 style header, and I shouldn't need that much
scaffolding to solve this problem.

Finally, despite recent changes in legislation, PGP is still crypto,
and there may be export problems.  An HMAC isn't; it's just hashing,
and so doesn't have those problems.

	- Dan C.