From: dlv@bwalk.dm.com (Dr. Dimitri Vulis)
Date: Wed, 4 Oct 95 12:47:47 PDT
To: cypherpunks@toad.com
Subject: Re: FORGED CANCELS of posts on n.a.n-a.m
In-Reply-To: <modemacDFr0qB.IyK@netcom.com>
Message-ID: <V0BgcD4w165w@bwalk.dm.com>
MIME-Version: 1.0
Content-Type: text/plain


[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