From: jbaber@mi.leeds.ac.uk
Date: Fri, 8 Aug 1997 21:41:41 +0800
To: aba@dcs.ex.ac.uk
Subject: Re: REPOST : Un-forgeable Cancels
Message-ID: <12952.9708081327@misun2.mi.leeds.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain




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?)

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.

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