Re: v01: mapping out the new draft.

New Message Reply About this list Date view Thread view Subject view Author view

From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Fri Sep 12 1997 - 06:31:59 CDT


Dave Barr <barr@cis.ohio-state.edu> wrote:

>In message <19970911002726.51138@clari.net>, Brad Templeton writes:
>>Just say, "If you want to cancel your articles, get a program to send signed
>>cancels" is in fact easier than saying, "If you want nobody else to be
>>able to cancel your articles and you want to cancel them, get a program to
>>put cancel-locks on every article you post and a program to issue cancels
>>using the locks."

>perspective.

>Cancel locks solve the key management problem. ....

>Public key signatures for usenet cancels are bad.

Oh no they're not!

Oh yes they are!

Problem is, people are assuming you need one or the other of them. This is
false.

There are two cases to consider:

1. The cancellation is by an ordinary user of his own article (or by a
moderator). The ordinary user is unlikely to use PGP or have a public key.
His user agent is ancient and crummy.

        In this case, the rule stays as at present. IF the From: (or the
        Sender: or the Approved:) in the cancel agrees with the From: (or
        the Sender: or the Approved:) in the original, AND IF the
        Originator-Info: confirms that From: (or Sender: or Approved:),
        AND IF Path: verification shows that the Originator-Info: indeed
        came from the apparent posting agent, then the cancel is valid and
        should be honoured. If the posting agent has signed the
        Originator-Info:, that is an added bonus. You might extend the
        rule to permit cancellation by
        usenet@the-server-in-the-Originator-Info.

        This provides a smooth transition from the existing rules, as more
        and more posting and relaying agents implement Originator-Info:
        and Path: verification.

2. The cancellation is by a 3rd perty canceller.

        In this case, the true canceller must appear in the Approved: line
        (to be verified by Originator-Info: and Path: verification as
        before). In this case one should require a digital signature as
        well. At least that requires only a much smaller number of public
        keys to be around. Moderators will probably have well-known keys
        anyway (for PGPmoose stuff), and professional cancellers certainly
        should have them. However, it is still too much to expect that all
        sites will necessarily bother to check the signatures. Some big
        sites may do so, and some may even issue cancels for the cancels
        if they do not check (again, PGPmoose-style). Note that this only
        works for massive cancellation if many cancels are included in the
        same message (only one signature to verify). This will need a
        rethink of the $alz convention, of course.

>Cancel locks aren't a problem for spam cancellers, since the current
>NoCeM system will still work, and it's far better performance-wise anyway.

I disagree. Spam cancelling is an "opt out" method. ISPs and other sites
have to decide consciously not to accept them. More accept them.

NoCeMs are an "opt in" method. ISPs have to decide consciously to implement
cancel-on-spool. Moreover even then, they still propagate the spam. I
doubt many sites actually implement cancel-on-spool, especially the big
ISPs, because they are scared stiff of being accused of "censorship" and
of losing their supposed "common carrier" status.

OF course, in the long run, the only way to stop spam will be to stop the
ISPs that tolerate it. But being able to establish the exact source of any
article (or cancel) is an essential first step in that process.

-- 
Charles H. Lindsey ---------At Home, doing my own thing-------------------------
Email:     chl@clw.cs.man.ac.uk   Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506       Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5


New Message Reply About this list Date view Thread view Subject view Author view


This archive was generated by hypermail 2b29.