[alt.religion.scientology restored, since that's where most of the discussion of forged cancels has been taking place so far ] In article <44pmiq$h7t@segfault.monkeys.com>, rfg@monkeys.com (Ronald F. Guilmette) writes:
In my opinion, the simple, obvious, and correct solution (which should have been implemented from day one, IMHO) is to modify the currently prevalent news processing packages (i.e. INN and Cnews) so that rather than physically removing canceled news article files from the directories where they exist, they are instead edited (by INN and/or Cnews) in place, and retained for future reference.
Because of the prevalence of forged cancels, my site just ignores all cancels. Unfortunately, most other sites, including our feeds, honor forged cancels. [Good suggestions skipped]
Bottom line: Article cancelations are known to be based upon highly in- secure mechanisms. Forged cancels are becoming more common. Many of these are desirable deletions of spam. Others are problematic instances of untrustworthy individuals attempting to act as unelected news admini- strators for the entire Internet. Until such time as more secure article cancelation mechanisms are put in place (and perhaps even afterwards) mechanisms which provide for the retention of adequate audit trails relating to canceled articles should be created and widely adopted. The current approach/convention/solution/mechanism of physically *deleting* an article file whenever _anybody_ on the world-wide Internet tells your news system to do so is simply not acceptable.
The cancellation mechanism described in RFC 1036 does not use digital signatures, but is based on the honor system. RFC 1036 says in section 3.1: "Only the author of the message or the local news administrator is allowed to send this message." However no mechanism is provided to authenticate the origin of a cancel. Of late, a small group of control freaks has abused this security hole, claiming (with no basis in reality) that some sort of consensus permits them to act as the self-appointed judges of the contents of other people's Usenet articles, to impersonate other posters, and to distribute forged cancels to other sites to censor the offending articles. E.g., one graduate student at Lehigh University falsely claims to be a sysadmin and regularly forges cancels for articles in n.a.n-a.m critical of his forgeries and other net-abuse; and a crtiminal cult has been forging cancels for articles discussing its dogmas. I'd like to remind everyone of the well-thought-out scheme for authenticating cancels proposed some time ago by Taneli Hujskonen and Benjamin Franz, that can also be integrated into a Lazarus-like system for tracing forged cancels. Let H denote a one-way hash function (also known as message digest), such as Ron Rivest's MD5 or Ralph Merkle's Snerfu. Efficient source code to compute them is readily available and not subject to export restrictions, unlike PGP. Such functions have the property that's it's easy (for a computer) to compute M = H(N), but, for a given M, it's intractable to find N such that M = H(N). Let the poster specify a secret passphrase whenever s/he posts an article. This passphrase will be required to cancel the article. However it will not be revealed by a cancel and can be reused. With user-friendly software, the poster might store the passphrase in a profile and use the same passphrase for all articles, or change it for every message. 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". When an attempt is made to cancel/supersede an article X with a "Cancel-lock:" header, the user is asked to supply the passphrase. The posting software computes M1 = H(X's body + newsgroups + X's message-id + date + passphrase) once again and adds the "Cancel-key: M1" header to the article containing "Control: cancel <X>" or "Supersedes: <X>" that's being posted. (Note that without knowing the passphrase it's intractable to match the M1.) Whenever news server software (such as inn) detects either "Control: cancel <X>" or "Supersedes: <X>", INN should retrieve the original article <X> and looks for the "Cancel-lock: M2" header. If one is found, then the old article may be cancelled only if the new article contains the header "Cancel-key: M1" such that H(M1) = M2. If the cancel cannot be authenticated (e.g., because the original article lacks the "Cancel-lock: M2" header, or the cancel lacks the "Cancel-key: M1" header such that H(M1)=M2), then INN should forward the unauthenticated cancel to one or more "collection centers" so the author of the original article may be notified. A site may choose to honor the unauthenticated cancel anyway if the article being cancelled lacks the "Cancel-lock: M2" header, but should ignore it if "Cancel-lock:" is found, but no matching "Cancel-key:" is given. Each "collection center" deamon should wake up periodically (say, every hour), group the collected unauthenticated cancels by message-ids of the cancelled articles, and e-mail the (distinct) addresses (other than "usenet@*" or "news@*") mentioned in the "From:", "Sender:", "Authorized:", and "X-Cancelled-By:" headers, quoting the unauthenticated cancel and the Path's as seen at many different sites that forwarded the cancels. This way, if the unauthenticated cancel is indeed forged, its author will see within hours that it has been fraudulently cancelled _and_ will automatically receive enough "Path:" samples from all over the world to see where it was posted, by comparing the "Path:" headers in several forwarded copies. A user or an entire site can easily "opt out" of havings "bona fide" cancels reported by always using the proposed "Cancel-lock:/Cancel-Key:" headers. This scheme would be upwardly compatible with all existing Usenet software. It would also be compatible with the "NoCeM" proposal, where trusted censors could issue digitally signed "advisory cancels" without impersonating the original posters. Such advisory cancels would not be subject to hash checks. --- Dr. Dimitri Vulis Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps