pst@anise.acc.com (Paul Traina) (08/10/89)
Steve Hayman at iuvax.cs.indiana.edu brought up a valid point in a quick note discussing cancel messages. He said it's a shame that it is so easy to cancel messages. He's right, In about 15 minutes I wrote an awk/shell script that would cancel any message that was piped to it. It took about 1 minute of looking at a legitimate cancel message and another minute to figure out that things were based on the Sender field instead of the From field. So, with this in mind, I am begining to think that it wouldn't be a bad idea if every message that gets created has an additional field which is based upon some public key cryptography techniques. Here is something that I'm thinking up as I write it, so don't take it as my endorsement of "a good idea". Create a new version of postnews/Pnews/etc that looks for a file in the user's home directory ~/.postcrypt. If there, it takes that as 1/2 of an encryption key. If it's not there, it asks the user to enter a plaintext phrase which then gets reduced to a key and stored in ~/.postcrypt. When the user posts a message, an encrypted Authorize-Key: field is added which is based upon the .postcrypt key and the message id of the actual msg. If the user desires to cancel the message, we just go back to the .postcrypt key, mung things together, and the cancel message gets sent out with a "Control-Authorized:" field which contains the proper key to allow canceling of the message. By doing it this way, we add no more processing time on "relay" systems, and only a slightly additional amount of overhead on the initial post and cancelling of a message. For backwards compatibility, if a message doesn't have an Authorize-Key: field, then the old rules (i.e. no real rules) apply. Comments? Is this a good idea that can be expanded to deal with rmgroups et al too? Or is there no real need to bother with it? -- The Constitution isn't all that great, but it sure beats the hell out of what we're using now.
erik@naggum.uu.no (Erik T Naggum) (08/10/89)
A few immediate reactions to Paul's proposed authentication keys: - When posting, we have the message-id and the .postcrypt file. We can produce the Authorized-Key field from these. - When cancelling, we must have both parts to get the check, and we will reveal the .postcrypt contents, if it sent as the Cancel- Authorized field. Thus, the .postcrypt file needs to be changed after each cancel, right? - If we change the .postcrypt file, we need a mapping between .postcrypt contents and message-id, to be stored with the user for some time. Might as well invent something to be used for key and log that. - Or, we could send out the same value in the Cancel-Authorized as in the Authorized-Key field. Kinda defeats itself, right? I don't think it's a good idea to use information embedded in the article for authorization. However, is there anything else? Wouldn't it be better if we could trace where a message came from, and reject it if it had followed a different path than over the one we got it? (Duplicates are a problem here. We must then log every duplicate to an article and compare against, so this can also be defeated, but with a much narrower range.) Cancel messages which followed another path are dropped in the great bit bucket where the duplicates also go. Much overhead and not much gains, I suppose. Just an idea. Cheers, --Erik T Naggum +----+ +----+ <erik@naggum.uu.no>, <enag@ifi.uio.no> === | === / Naggum Software & Communications === | === / POB 1560 VIKA; 0118 OSLO; NORWAY; +472-717-822 +----+ +----+ "These are my opinions, and not those of my employees." PS: Do you trust your government?
smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (08/10/89)
Sure, public-key cryptography would work, though the implementation
details can get tricky. We knew that way back when, when we designed
the very first release of netnews. It deliberately had no control
messages because we knew that short of cryptography there was no way to
authenticate them.
Why didn't we implement one? Well, it's harder than you might think.
Bear in mind that what is needed is a system good enough to stand up to
a hacker or malicious legitimate user willing to crunch for a week in
the background on {spare|stolen} cycles on a large machine, while still
being cheap enough to run on a small one. (If I need to, I can use
a Cray. I'm not the only one.)
It's also unclear what algorithm to use. RSA is patented (though the
patent hadn't been granted at the time). Knapsack has been broken.
Other schemes are proposed regularly, but their worth is unclear.
Incidentally, we don't need public-key cryptography; what we need is
digital signatures, i.e., something that provides a (public key)
cryptographic checksum without necessarily providing secrecy. The
distinction is important; there are a number of algorithms that provide
just the signature function.
I suspect that the best bet for the near term is to piggyback off of
the privacy-enhanced electronic mail being adopted for the Internet.
See RFC 1040 for details. An agreement has been negotiated to use RSA
(*with* payment of licensing fees, thank you). It may be both
technically easy and legitimate given the terms of the agreement with
RSA Data Security, Inc., to use much of the same code, formats, etc.
Unfortunately, I have not seen any public statement on just how the
licensing will work.
--Steve Bellovinhenry@utzoo.uucp (Henry Spencer) (08/10/89)
In article <12007@ulysses.homer.nj.att.com> smb@ulysses.homer.nj.att.com (Steven M. Bellovin) writes: >Why didn't we implement one? Well, it's harder than you might think... We considered it for C News as well, particularly when Bob Webber was being obnoxious about moderated groups. We came to pretty much the same conclusion: it's hard, you really need serious-cryppie help, and the choice of algorithm is a problem. (Not to mention, it's not good for performance.) So we said "not just now". -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
tneff@bfmny0.UUCP (Tom Neff) (08/10/89)
If you added an authenticating signature ID to each message, you would need to modify the Cancel procedure to prompt the cancelling user for a password. It would be impractical to require a password for each posted article, so the poster's login password would have to be used instead. I think. -- "We walked on the moon -- (( Tom Neff you be polite" )) tneff@bfmny0.UU.NET
brad@looking.on.ca (Brad Templeton) (08/11/89)
In many ways USENET takes the original Unix philosophy. Remember the introduction to Unix that started with, "here's how to crash Unix?" Nobody bothers, because it's so easy. On USENET, forging a message is no challenge. It happens pretty rarely, really. If you used cryptosystems, you would have to appoint one single person who could issue control messages, and if that person left or got irresponsible, then *everybody* would have to change very quickly. Pretty messy. -- Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473