Re: FORGED CANCELS of posts on n.a.n-a.m
At 10:47 AM 10/4/95 EDT, dlv@bwalk.dm.com (Dr. Dimitri Vulis) wrote:
When an article is posted, two quantities are computed by the posting program: M1 = H(article body + newsgroups + message-id + date + passphrase) and M2 = H(M1). The posted article contains the header "Cancel-lock: M2". [.. Cancel-key: M1 to cancel or supersede.] [..Daemons forward suspected forged cancels to originator]
Aside from the forged-From:-bogus-cancel spam /r$ proposed, this has the problem that it still only allows the originator to cancel a message, and not either the moderator of a moderated group or a Good Spam-canceller like CancelMoose, as well as stopping censors and cancel-spammers. Cancellation is a sufficiently local-policy-dependent issue, and reasonably low volume compared to the rest of news, that it probably makes sense for the various news programs to hand cancellation requests off to an external program, which can be locally modified as desired. One approach is to add digital signature and verification capability to News, at least to support cancels; doing this in an outboard cancel-daemon is obviously easier. RIPEM-SIG is a signature-only version of RIPEM which is exportable, probably just in binaries. The local cancel-daemon could accept cancellation requests that were signed by anybody on the list of locally-approved cancellers; one site could accept cancels from Cancelmoose, newsgroup moderators, and Helena Kobrin; another could do authors only. This would, of course, encourage people to get their digital signatures out there to allow themselves to cancel their own messages. ---------------- BTW, on the general topic of spam, I got a nice note back from the Johnson-Grace folks saying they were sorry they posted their ad/announcement to the list and it won't happen again. And you can download their compression stuff from www.jgc.com but they're not actually making the algorithms public... ----- #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts@ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---
In article <4571p9$kf5@kruuna.helsinki.fi>, wirzeniu@cc.Helsinki.FI (Lars Wirzenius) writes:
dlv@bwalk.dm.com (Dr. Dimitri Vulis) suggests that cancels be authenticated so that only the actual poster could cancel them. He notes that this would make it impossible for moderators to cancel forgeries, but says they could use NoCeM notices instead.
Speaking as the moderator of comp.os.linux.announce: No way!
NoCeM doesn't work, since most people have never even heard of it. [Valid criticisms of NoCeM skipped] (Approval forging can fairly easily be made very difficult: the moderator digitally signs the articles, and all major news servers are fixed to drop all other articles on the floor. The problems with this approach are that on the one hand, upgrading a lot of news servers to the new software is a bit of work, and on the other hand, even digital signatures may be, or become illegal in parts of the world. But that just might be a reason to implement it now. There's work being done on it, as a matter of fact.)
Sorry for the belated follow-up -- I was far away, and now have a backlog to sort out. I've discussed the Hujskonen-Franz proposal some time ago with the beautiful Simona Nass from Panix and the Society for Electronic Access, and she made the following suggestion: let each party that wants to be able to authorize cancels add their own separate Cancel-lock: headers. The cancel/supersede should be honored if its Cancel-key header matches any one of the Cancel-lock challenges. I think adding multiple Cancel-lock: headers, any single one of which needs to be matched, to the Hujskonen-Franz proposal will address _some of the concerns expressed by Bill Stewart last week, by Lars Wirzenius, and by CancelMoose him/herself in http://www.cm.org/about-cancels.html about the ability of moderators to cancel postings in their own newsgroups. Scenario 1. Alice posts an article from a computer owned by Bob, an Internet provider. Bob wants to reserve the right to cancel Alice's account and Alice's Usenet postings without Alice's permission if Alice misbehaves (e.g., spams). Alice posts: ]From: alice@bob's.box ]Newsgroups: alt.sex ]Subject: Call me at 1-800-xxx-xxxx for a good time ]Message-id: X (123@bob's.box) ]Cancel-Lock: M2_a where M2_a is the one-way H(X + M1_a), and M1_a is H of the article and of Alice's secret passphrase. Bob, being the sysadmin and the owner of his box, configures his news-posting software to add automatically a second challege, in addition to Alice's: ]Cancel-Lock: M2_b where M2_b is the one-way H(X + M1_b), and M1_b is H of Alice's article and of _Bob's secret passphrase. Bob asks Alice nicely to cancel the article, since such ads are not appropriate on alt.sex. Alice may comply and issue a cancel with the header ]Cancel-Key: M1_a which will be honored. But if Alice refuses, Bob can issue a cancel/supersede with the header: ]Cancel-Key: M1_b which should likewise be honored because H(X + M1_b) matches one of the two challenges in the posted article. Note 1: If Alice doesn't add a Cancel-Lock, and Bob does, then Alice won't be able to cancel her own article. Note 2: It may be a good idea to put comments on the challenges: ]From: alice@bob's.box ]Newsgroups: alt.sex ]Subject: Call me at 1-800-xxx-xxxx for a good time ]Message-id: X ]Cancel-Lock: M2_a ; alice@bob's.box ]Cancel-Lock: M2_b ; root@bob's.box Scenario 2. Alice submits an article to Bob, a moderator of a moderated newsgroup: ]Newsgroups: rec.food.cannibalism ]Subject: How to cook elementary school children ]Message-id: X ]Cancel-Lock: M2_a where M2_a again is H(X + M1_a), and M1_a is H of the article and of Alice's secret passphrase. Bob, being either the sole moderator, or a team member, adds an approval and a second challege, in addition to Alice's: ]Approved: Bob ]Cancel-Lock: M2_b where M2_b is the one-way H(X + M1_b), and M1_b is H of Alice's article and of a secret passphrase used by Bob or by the entire moderating team. Later Bob can cancel this article by specifying ]Cancel-Key: M1_b Alice too can cancel this article by specifying ]Cancel-Key: M1_a (unless Bob has stripped Alice's challenge before posting her submission) and Alice's sysadmin can cancel it too if he added his own challenge (third). I personally don't think that Bob should be allowed to cancel Alice's article after he approved it, but that's between Alice and Bob; if she doesn't like it either, she can post her articles elsewhere. Now, if Alice injects an article with "Approved:" and entirely bypasses Bob, (Lars Wirzenius's main conern), then Bob should post a PGP-signed NoCeM notice and try to yank Alice's feed, or have the site that continues to permit Alice to do this to be widely aliased. IMVHO, when this happens, the problem is much deeper than just having the unauthorized article removed. If and when NoCeM becomes widely accepted, most sites can be expected to honor signed 'Action: hide' requests from newsgroup moderators in their groups. Scenario 3. Alice provides dial-up Usenet feed to/from several small sites run by Bob, Charles, and Dan. Their domains point to Alice via MX. Alice knows that if one of them spams Usenet, she'll be flamed and mailbombed. Alice adds her own "Cancel-Lock:" to each article she receives from these sites before feeding them to the rest of Usenet. Later she can cancel whatever articles have originated at B, C, D, and passed through her site. If Bob, Charles, and Dan don't want Alice to be able to cancel their articles, or if Alice adds other headers in the articles that pass through her site that they don't like, then they can look for another feed. Please note that I don't claim credit for these proposals: I'm just repeating others' ideas which I happen to like a lot. I hope some civic-minded person(s) will write patches for the common posting/server software, and compose an RFC for the Cancel-Lock:/Cancel-Key: headers. One nice feature about the Hujskonen- Franz proposal that it can be adopted gradually: some sites can continue to honor all cancels, while others can choose to start honoring only authenticated cancels, and to help track down forged cancels that fail authentication. P.S. I saw a NoCeM notice from Chris Lewis with Action:hide/Type: copyright, for someone's Usenet article that, I think, quoted his private e-mail (?). I wonder if CancelPoodle's NoCeM's for the Top $ekret $ientology $tuff will follow soon. :) (And the NoCeM documents should probably be updated to support new types: copyright, libel, flame, inappropriate, ... :) :) :-) ObMoosePoem: :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) Moose, Moose, wonderful Moose! Gets rid of nasty spam. So fond of the Moose I am. Hooray for the wonderful Moose! :-) --- Dr. Dimitri Vulis Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps
On Mon, 09 Oct 1995 23:12:35 -0400 (EDT), dlv@bwalk.dm.com (Dr. Dimitri Vulis) wrote:
Scenario 3.
Alice provides dial-up Usenet feed to/from several small sites run by Bob, Charles, and Dan. Their domains point to Alice via MX. Alice knows that if one of them spams Usenet, she'll be flamed and mailbombed. Alice adds her own "Cancel-Lock:" to each article she receives from these sites before feeding them to the rest of Usenet. Later she can cancel whatever articles have originated at B, C, D, and passed through her site.
I like this a lot, except: If B doesn't add a Cancel-Lock to each article he sends, he loses the ability (because of Alice's Cancel-Lock) to cancel his own articles. Cancel-Locks should only be added (or honored?) if the message contains a Cancel-Lock from the originator. I'd also like to suggest that added Cancel-Locks be generated from something less than the full message -- perhaps from just the message ID. Intermediate sites are unlikely to maintain full copies of all messages, and ought to be able to generate cancels in response to a (possibly corrupted) copy returned to postmaster from another site.
[A quick last word before I leave for a wilderness area with no net.access.] In article <199510051540.IAA23612@ix.ix.netcom.com>, Bill Stewart <stewarts@ix.netcom.com> writes: [Hujskonen-Franz]
Aside from the forged-From:-bogus-cancel spam /r$ proposed, this has the problem that it still only allows the originator to cancel a message, and not either the moderator of a moderated group or a Good Spam-canceller like CancelMoose, as well as stopping censors and cancel-spammers.
The respected CancelMoose no longer posts cancels, but posts PGP-signed NoCeM notices. In fact, CancelMoose's web site has some nice things to say about the Hujskonen-Franz proposal. I quote URL: http://www.cm.org/about-cancels.html: ]About Cancels ]************* ] ]A number of people have asked about the relationship between this project ]and spam cancels. IMHO, the point is moot. ] ]I envision unauthenticated cancel messages will rapidly become obsolete, ]once people start posting menu driven cancelbots. If we want cancels back ]we'll have to authenticate them. ] ]Taneli Huuskonen first suggested this scheme to me, and I think it's an ]excellent idea. ] ]For every posted message there is a "Cancel-Key" which is the message-id of ]the message hashed with a secret password. The MD5 of the cancel-key is the ]"Cancel-Challenge" which is posted as a header in every post you make. To ]cancel that post, the cancel message must have a copy of the Cancel-Key in ]the headers. An admin can configure his news software to add another ]Cancel-Challenge to the post, if he/she wishes to retain the rights to ]cancel it. The only people this leaves out in the cold is the moderators-- ]this does not allow them to protect their newsgroup-- perhaps a public key ]based system to "prove" moderation will prove necessary, but that will ]require some MAJOR reworkings of news... ] ]Email: moose@cm.org I urge cypherpunks to read the NoCeM information on URL http://www.cm.org/ and to jump on the NoCeM bandwagon (such as, start posting PGP-signed "show" ratings for articles we find worth highlighting). I see nothing in RFC 1036 that says that a moderator of a newsgroup should be able to cancel other people's posts in his/her group. There's an old Usenet tradition (bad, IMO) that when Alice posts an article in Bob's moderated group and inserts her own "Approved:" header, then Bob is expected to impersonate Alice and to post a cancel in Alice's name for the unauthorized article. But, at present, nothing prevents some Charlie from impersonating Bob impersonating Alice and forging a cancel for an article that actually was approved by Bob. Basically, if Alice posts an article with her own "Approved:" header in Bob's newsgroup, then this problem is not going to be solved by just cancelling her article(s). If Alice keeps doing that, it becomes necessary to talk to her feeds about aliasing her site, and the cancels have little to do with it. IMVHO, only the author should be able to cancel her own postings in a moderated group. If the posting was not properly approved, she should cancel them to show good will. Once Bob has _approved Alice's posting in his moderated group, he shouldn't be able to impersonate Alice to cancel it, but should ask Alice. (And all this can be done with the Hujskonen-Franz scheme.) Bob can instead protect his newsgroup by posting a PGP-signed NoCeM notice: Action: hide Type: unauthorized posting or by asking someone widely trusted, like CM, to post such a notice. Likewise when Brad Templeton and/or Co$ (sorry Brad for lumping you together :) see an article which they think quotes their copyrighted material, they should not forge a cancel, but post a PGP-signed NoCeM notice: Action: hide Type: copyright violation I wonder how many sites would honor CancelPoodle's NoCeM notices? :) The Hujskonen-Franz scheme would still allow Clarinet to continue massively canceling/superseding their own articles. Continuing to quote Bill Stewart:
Cancellation is a sufficiently local-policy-dependent issue, and reasonably low volume compared to the rest of news, that it probably makes sense for the various news programs to hand cancellation requests off to an external program, which can be locally modified as desired.
It would be nice if inn and nn called the same external program to handle cancels. Now nn's database easily gets out of sync. With an external program, each site could choose to honor only authenticated cancels and ignore 3rd party NoCeM's (but let the users mark NoCeM'd articles as read, if they want to); or honor all cancels; or something in between.
One approach is to add digital signature and verification capability to News, at least to support cancels; doing this in an outboard cancel-daemon is obviously easier. RIPEM-SIG is a signature-only version of RIPEM which is exportable, probably just in binaries. The local cancel-daemon could accept cancellation requests that were signed by anybody on the list of locally-approved cancellers; one site could accept cancels from Cancelmoose, newsgroup moderators, and Helena Kobrin; another could do authors only. This would, of course, encourage people to get their digital signatures out there to allow themselves to cancel their own messages.
Any idea that encourages people to use digital signatures is good. However the Hujskonen-Franz proposal allows a total stranger to post an article to your news spool; then to cancel this article, with your being reasonable sure that the cancel came from the same total stranger, and without establishing any further trust for the stranger. There are tens of millions of people with Usenet access. It's an overkill to collect a key from each one to allow them to cancel their articles. NoCeM is a very promising protocol for allowing trusted third parties to eliminate articles by posting PGP-signed notices. (e.g., CancelMoose new way of killing spam -- no more forged cancels from CM!) ObMoosePoem: :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) Moose, Moose, wonderful Moose! Tramples spam with a hoof; Spammers go through the roof. Moose, Moose, wonderful Moose! Rids us of ugly spam. Fond of the Moose I am. Moose, Moose, wonderful Moose! :-) I have to go _right _now. --- Dr. Dimitri Vulis Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps
participants (3)
-
Bill Stewart -
dlv@bwalk.dm.com -
John Lull