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
#---

[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

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.