Brad Templeton Internal Page

How to authenticate cancel messages today

How to authenticate cancel messages today

There is a serious problem on USENET, with:

  1. Malicious users sending out cancel messages on other people's messages
  2. Some sites ignoring all cancels, even valid ones, to avoid this
  3. Other users reposting cancelled messages as a "favour" to the victim, resulting in waves of reposts.
  4. Vast amounts of spam and other bad postings needing legitimate trusted 3rd-party cancel

Various methods of authenticating cancel will take years to be widely adopted, if the speed of past USENET software upgrades is any indication. However, these rogue cancels affect everybody, not just the user who made the original post. If a message I want to read is cancelled, then I and the rest of the net are harmed and can do little about it.

The Types

Cancels can be authenticated by two means. One is called a cancel lock. It's the secure hash (MD5 for example) of a secret string unique to the message. If one is kept with a message, you can, in the cancel, include the original secret string and prove you are the original poster.

The other means is with public key digital signature, and a certificate stating you are authorized to cancel the message for a variety of reasons (you are the party named in the From or Reply-to or Sender or Approved, or the site of that party, or the site named at the injection point in the path line, or the site named in the message-id, or finally just a trusted 3rd party for the net, a site, or a newsgroup or other subset of the net.)

The cancel locks are simpler, but demand the PK digital signature cancels for the 3rd parties that are needed to stop spam. However, on their own, neither authenticates cancel until years later, when a lot of users start using them and a lot of sites start checking them.

A solution now

A few years is too long to wait. Here's an answer.

First we declare that the old, unauthenticated cancel is dead. Not only will sites with new software ("new sites") fail to execute them, they will refuse to propagate them in their original form. This stops the rogue cancel (or any old style cancel) from making it very far on the net, once a variety of key hub sites have new software.

The new sites would not just not propagate the old cancels, they would rewrite them, but keep the message-id. They would turn them from a "Control: cancel" to a "Control: oldcancel" The oldcancels would be ignored by sites with old software. They confirm the From line before rewriting. If they don't have the original, they don't forward the cancel.

Very quickly, old style cancels would become ineffective, even at sites that haven't updated their software in years.

Cancels which contain an authentication, either the unlocking secret string of the cancel lock, or a public key based digital signature, would propagate, and be effective all over the net. At old sites, they would be unchecked, of course, but new sites would check them, and refuse to forward them if they failed their check.

Users with new software, able to issue an authenticated cancel, still have a working cancel, net-wide, except at sites that have old software but have deliberately disabled all cancels. One hopes those sites would reverse that decision with this new system in place.

Users of old software

Of course a solution is needed for the users of old software.

Sites with new injectors

At sites that do the injection of news (typically via the NNTP POST command) it will be possible for new software to be able to put a PK digital signature on old style cancel messages that are injected, presuming the site has some way to verify the users who are using it. Those users need do nothing more -- they gain authenticated cancels.

In addition, users could also arrange to use another injection site that is running new software, but which asks them for some authentication and confirms their E-mail address with E-mail challenge/response.

Truly old software users

If you are using old newsreading/posting software, and using an old injection site, you will issue an unauthenticated cancel. And it will go out over the net, going through old relay sites. And at those sites it may act without authentication.

Until it gets to a "new site." That new site won't act on it, but will turn it into an oldcancel. That oldcancel will flood the net just like any other article.

Today there are about 1000 author issued cancels per day. The number of cancels issued by users with old software at sites with old injectors will be less, and will dwindle with time as new software comes online. So the volume of these oldcancels will not be large.

The Cancel Signers

As a service to these old users, a small number (perhaps just 2) of sites will provide a cancel authentication service. These will be machines with a trusted 3rd party cancel certificate, much like the spam cancel services. (Indeed, they may be the very spam cancelers.)

They will get the oldcancel messages. Both through normal flood, and because a fair number of the "new sites" will arrange a direct NNTP feed of only the oldcancels to them. This is not a big load, because the IHAVE protocol assures they get each one only once. They also share amongst one another.

Then they divvy up the oldcancels. More on that later.

For each oldcancel that is their duty, they send E-mail to the user who posted it. This E-mail says:

Greetings. You have posted a "cancel" message -- a request to delete a message you posted -- for your message-ID <X@Y>. (Include details about message if present on system.)

Your news software is an old version, and it doesn't provide any way to prove that the cancel message came from you. Today, USENET sites insist on such proof. Otherwise any user on the net could delete your messages, and you probably don't want that. This means we need to confirm that the cancel request really came from you.

That's easy to do. All you have to do is reply to this E-mail. Any reply at all -- even a blank one. We'll get the reply, and that will confirm you really wanted to delete your message. Then we'll issue a new style cancel request in your name, and sites around the net will honour it.

If you have questions on how this works, or want to know how to upgrade your software to issue authenticated cancels directly, go to this URL.

Note: For reliability, on rare instances you might get two copies of this confirmation request. If you do, don't worry. Reply to either, or both of them.

This message has a From: line set to a magical address. That magical address has a site with a special MX, and a magic token which is in effect a digitally signed hash of the message-id being challenged.

The reply goes back to any site in the MX -- perhaps the special sites above, but not necessarily. Those sites use the signature right in the envelope "to" field and write a cancel message for the specified message-id, but their cancel is signed with a trusted 3rd party cancel key.

It goes out on the net and the cancel is executed. It has a special flag to assure flood propagation, so it even goes through sites that never saw the article. Again, the number of these is small and diwndles over time.

Sealed subnets

If a subnet is sealed off from the rest of net, two things can happen. In one instance, the net has no new sites, and so the cancel just acts within it as it always did. Rogue cancels are not a big issue in special local distributions.

If it has a new site, the new site needs to have a feed that will go out to the regular net, just for the cancel, so the oldcancel makes it to the cancel signer. Or the new site has to be a cancel signer, just for the local subnet. Once the cancel signer gets it, the flood brings it back.

Or finally, the new site can be configured to, within the small subnet, not do anything special with old cancels. Just act on them, as in the old way. It just needs to have a file to configure which subnets don't get the special oldcancel mapping treatment.

Sharing the work

We want more than one site to do this, for reliability. But since the load is low, we don't need a lot. 2 or 3 would suffice.

These sites need to be in communication, so that they would know if another one sent out a successful challenge. Here's one way it could work.

  1. When a signing site gets an oldcancel, it hashes it to produce a shuffled ordering of who should try the message 1st, 2nd, 3rd etc. If it's first, it does the challenge. It records this in a digest of challenges it issued, which goes into a special newsgroup shared quickly via NNTPLINK among the signing sites. The digests are spit out every few minutes.
  2. If it's 2nd, it waits a few minutes (the interval of a few digests) to see if the site that was 1st handled the message. If not, it takes it over and issues the challenge, and broadcasts that. If 3rd, it waits a bit longer, and so on.
  3. If a site goes down, when it comes up it first reads all the digests, and sees if there are any messages that it still needs to challenge. If so it does them.

The responses to the challenge come back independently, to these machines or possibly even to others. They use MX for their reliability.

In this way, most challenges go out quickly. If a system is down they are delayed slightly. You could work hard and reduce this delay but there is not a big need.

In fact, there are other ways the sync could be performed, from IP multicast, to regular checking of the up-status of the other sites. How it's done is not important. It doesn't even matter if rarely the sync fails and two sites issue the challenge. It just means the user gets 2, and they can respond to either, or both.

The Result

This system, whether on top of cancel lock or PK signed cancels, gives us authenticated cancel as soon as the signing systems are in place and a few "new sites" take up positions at perhaps just a few dozen major hub points in the net. In other words, it can happen in days after the software is ready. Not years.