Glad that the mail got through that time - not forged cancels though I am sure, more likely a cock up with my mail sppol.....

Adam Back <aba@dcs.ex.ac.uk> writes: Sounds good to me. I thought there was someone doing something like this with hashes. But then I never really looked into any of the systems. What does Greg Rose's PGPMoose do? (One presumes it involves PGP sigs?)

From what I can see (the full README is unavailable) PGPMoose is designed to Cancel messages in a moderated newsgroup that have not been approved by

I must admit that not being a news admin and rarely posting to news I have not realy looked at what is being worked on. I was just reading the 'forged cancels' thread when I though of the hash idea. the moderator - by using PGP sigs to authenticate the approval. see http://people.qualcomm.com/ggr/pgpmoose.html This could be modified for general cancels but would then involve PGPMoose having access to every authors Public Key.

...

This does assume that message IDs are available by the news program and are not allocated after sending. If this is not the case then it would be necessary to use other header information to calculate the hash such as the date/time and subject, or to store some kind of key at the authors end in order to reference the message (although in this case X may as well just be generated randomly and stored).

I think you don't even need this much uniqueness of hashing material...

Personally I would prefer a unique value for every message, especially if I was a prolific sender of news.

Say you just chose a random R and store it in ~/.news-preimage, and HASH( R ) in ~/.news-image.

Now you post all of your posts with HASH( R ) in a header as you are suggesting.

Now if you didn't want to be coerced in to cancelling your own posts you just remove .news-preimage instantly.

You have to update your preimage for each cancel you do, but how many cancels do people do anyway? (Not many for their own benefit I reckon).

This would work well but would allow an attacker to cancel any message sent using that value of R as soon as the author sent a message. Generally the more messages that you sent the more vulnerable you would be to this (as more of your articles would still be in the news feed) - exactly how much of a problem this would be depends on whether archivers accept cancels (which I doubt) and how long the news group in question is stored in the news spool before timing out.

This is a low security application, and ease of use over user typed passwords will win I think.

This I completely agree with, I was initally thinking of leaving the password as an Environmental variable set when the user logged on (.cshrc, .login, AUTOEXEC.BAT etc as appropriate). It makes very little difference if this is the case or if it was stored in a file, however a good news program could offer the option of using a different random/secret for any particular message if the author wanted it to be [more] secure from their systems manager.

Conceivably you could cope with the above by making .news-image readable to the news system on your local net news service. This could transparently do the job without needing to update any clients -- only an INN patch required. Sounds like a phun project for someone.

This is far simpler than if you calculate a unique hash for each new message and may be the part that wins the day.

Issueing cancels would be more manual, but you could easily knock up a perl script to instruct the NNTP server to do that. (Or windows program, or whatever).

I think that issueing cancels should be more complex than just clicking on a button - after all once you have said something there is very little reason to try to cover it up - in most cases a simple correction would do.

If you really wanted to integrate cancels without updating clients, for those that support them you'd have to give the NNTP news server access to your preimage, R. Not sure this is a good idea, as now your ISP can be coerced into cancelling your message for you without your cooperation.

This would generally be a bad idea, however you should remember that the NNTP news server could simply be modified to overwrite yor Cancel_Ref: header with their own value of Y anyway or even just not forward your article, just as any news admin could (any news admin can only change those 'down the path' from them).

Course all these problems go away if you do update clients, but it's usually nice to offer an easy interim migration path, else no-one will use it.

Adam

Again true, however this is true for any cancel checking mechanism. As far as I can see the advantage to this idea over digital signatures is that the NNTP program that has to decide whether to accept the cancel or not does not need access to the public key of the sender. Another thing is that the modification to the NNTP program is the same whether you use a unique hash per message or a stored ~/.news-preimage as all that it has to do is check that the value included in the cancel message hashes to the value in the original message. This would allow quick updates to both NNTP and the news-reader (probably originally using the stored preimage) and later versions of the news-reader to be updated to include the unique hash (which can still operate transparently to the user, using either a file or environmental variable) without having to make any changes to the NNTP program. Thanks for the comments, Jon http://chem.leeds.ac.uk/ICAMS/people/jon/