From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200309071905.h87J5Nj17542@augusta.math.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] re: spam filtering fs In-Reply-To: Your message of "Sun, 07 Sep 2003 08:35:59 EDT." <46abee0349bc972af8d87c15a1815507@plan9.bell-labs.com> From: Dan Cross Date: Sun, 7 Sep 2003 15:05:23 -0400 Topicbox-Message-UUID: 2e799c82-eacc-11e9-9e20-41e7f4b1d025 David Presotto 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.