From: Brad Templeton (brad@templetons.com)
Date: Thu Oct 11 2001 - 13:43:07 CDT
On Thu, Oct 11, 2001 at 10:46:20AM -0400, Bill Davidsen wrote:
> There is no poster's injector in a moderated group, the post goes by
> mail. You would have three CL max, unless someone thinks it's a good
> idea to allow cancels in mail.
Good point (should even be put in any CL spec) because it is usually the
poster's injector which mails the article to the moderator it might do it
but you're right it need not.
>
> PK and CL, by far. CL assumes only capability from the sender and reader
> site. It requires no OOB connectivity, trust, and can be readily
> implemented on at least most common server software by drop-in scripts
> and a little configuration. It is independent of a network of trust,
> however you implement that.
But if we're doing PK and CL we are already putting the PK software into
the sites, and building the trust relationships. That's my whole point.
I agree that CL is far simpler than PK if you're not going to do the hard
work of PK in the first place. But it's not simpler if you're doing the
PK anyway.
Turns out that having a trusted cancelbot (for spam) makes it orders of
magntiude easier to implement cancel by PK than it is to implement it by
CL. That's because you can do it with _no_ extra software in any news
reader, posting tool, injector or receipient site. You can't get much
simpler (for the authors of those tools) than zero, can you? The effort
is all in the cancelbot, which gathers cancels and issues challenge/responses
on them.
> Given that there are thousands of sites who don't apply any form of PK
> cancels now, I don't see how they work for everybody. They work for
> people who install software to use them, build the chain of trust, and
> are totally trusting of that chain. It won't work without implementation
> effort any more than CL will.
Of course any auth cancel requires the recipient of the cancel to have
new software to test it. We're presuming that, because it's a must for
spam. Whether it's PK or PK and CL is the only question. Because if you
have CL, all spam will be cancel locked, I think we all agree, and that
means you can't install CL code without also installing software to accept
trusted cancels from a cancelbot, not if you want a USENET that's usable.
So the big difference is that challenge/response cancel by a cancelbot
can be done with no new software for the user, but CL cancel requires that.
It is thus, for the user, which is who counts, infinitely simpler.
> This is bad why? Sites that don't implement CL will still honor old
> cancels, site who use nocem will continue to do so, sites who don't
> cancel anything now by policy will have a way to do verified cancels
> without trusting someone else to do their thinking for them.
Sites upgrade their software faster than users. I'm still running trn
which has not been upgraded in ages. Backbone sites are maintained by
professional sysadmins, and they upgrade much faster, especially if it
helps their site work and lowers their complaint load.
So I expect new software to be deployed first in backbone sites, then in
leaf sites, and slowly among users. I expect it to be many years before
most users have a new news poster.
I expect many sites which are accepting cancels now would quickly move
to only authenticated cancels.
Private users cancels, by the way, are relatively rare. Most users do
less than one a year. They won't upgrade just for cancel ability.
> And given the example of the invalid Verisign certificates for
> "Microsoft" we know that in practice this doesn't work perfectly, and
> arguably doesn't even work reasonably well.
Microsoft doesn't have 'control messages.' For newer versions of Windows,
it has 'windows update' which actually whines at you to manually install
the new certificate, and I expect most people have done it.
But that's not as automatic as a repudiation control message. In a properly
designed certificate system with a message stream as USENET has, highly trusted
parties can issue a control message that adds a certificate or key to the
certificate-revocation-list. (lookup CRLs in your google search)
You can either make revocation easy or hard, there are arguments either way
(since revocation can be used as a DOS.) One option is to use a different
key for revocation than for action, so that it is less likely the revocation
keys would be compromised.
You can't have a secure system without revocation, which is one of the
large flaws of what I think you're proposing. (I haven't actually seen
you draft it, have you?)
> In the real world I don't know how far it has to scale. You only need a
> few keys, not one for every user, or site. Maybe one key for every
> hierarchy which you want to control perfectly, one for moderator
> cancels, a few for cancelbots you trust (if any), not a huge number,
> and all able to be done in an automated way.
The scaling isn't just the number of keys, it's the number of sites.
You can't have a manually installed list of keys at 300,000 servers.
It won't work, it would take years to get a change deployed.
You also need more keys than you say. You need a key per moderator, and
there are hundreds of those, growing to thousands. And while not every
site admin or user would want a key, many would. Many people PGP sign
their articles today even though it's almost entirely useless to do so,
indicating they would like some level of authentication.
>
> > I don't want a trusted central authority. I want a generalized system
> > that gives site admins the ability to delegate trust to whomever they want,
> > including the ability to sub-delegate.
> That's what we do now, without certificates.
Huh? How can I delegate power?
>
> Which means I have to somehow validate that the person doing the cancel
> has some right to cancel the article. If the cancel is by a site admin I
> have to be sire that site has the right to cancel that article. Sorry,
> that's exactly why I want CL for single article cancels, I know that the
> cancel is good for that article, and that I am not trusting anyone to be
> well behaved.
Why not? For decades usenet existed where absolutely _anybody_, from
a scientologist to a cancelmoose, could cancel any article. It broke
down remarkably late in the game.
I wouldn't be that bothered if a huge number of trusted, identified people
had the power to cancel. It worked before.
One of the key things about PK certificates is that you can make an
ability (like cancel) never be anonymous. That means any time people
abuse trust, they do so in public, with a hard link to who they are and
what they did. (That doesn't apply to posting, you can issue certs for
anonymous email addresses of course, but you probably would not issue an
anonymous one with a special privilege like 3rd party cancel without real
trust first.)
Point is, if somebody abuses a key, it's done in public, literally signing
their work. And even if it were anonymous, you can revoke a key that's
abused.
> Making the process so slow that you eliminate the possibility of
> catching the "I shit I didn't mean that" post before people read, and
> probably quote, just what you didn't want to say.
My readings show propagation of messages to be very fast these days. The
cancel siphon would get lots of feeds of just "control" to make sure it
got messages from all over quickly. I expect if you didn't log off the
moment after posting the cancel, you would see the challenge in your
mailbox within seconds to minutes.
Remember, the alternative to this is that you can't cancel at all!
So even if it were slow, it's a better alternative.
>
> And PK provides no proof that the entity issuing the cancel is
> authorized to do so. That's why I think we need two systems, because no
> one system is remotely optimal for both single cancels and mass cancels.
In what sense does it provide no proof that the entity issuing the cancel
is authorized to do so? That's exactly what it does.
>
> the issue of proving that the sender is "trusted" somehow, without
> linking the trusted person to the action. Without that link the number
> of trusted people is a single digit number.
How don't they link the trusted person to the action?
> The easiest way to solve a problem is to redefine it so you don't need a
> solution. So use CL for individual cancels, and the number of keys
> managed drops to a few; tale, and a few spambots. Add tale distributing
> a list of hierarchy control keys via post and you're done.
We seek to authenticate moderated groups, not just cancel. Even tale's
list doesn't scale. What if somebody on it died? How long would it take
before all the sites on USENET updated their key? We would be unable to
create a group in that hierarchy for quite some time.
>
> In other words you are trying to find the best way to do something which
> need not be done.
I posted a list of features I think authentication should have, you want
to say none of them need to be done? You don't want to authenticate
moderators? You want to centralize all cancel decisions with long-term
spambot operators, and not put it in the hands of site admins and people
managing hierarchies? You don't want the ability for users to authenticate
their own posts and stop forgery? You don't want the ability to create
different kinds of newsgroups which would be mostly spam-free (not
spam-cancelled, but spam free) though not pre-moderated? You don't want
the ability to revoke keys? The ability to run a news site without having
to configure stuff every time a moderator changes?
>
> Moderated groups would have public keys in the create message. Signed
> messages would be automated, other evaluated by hand (or honored or
> ignored at site option).
What if the moderator changes? What if the moderator wants to delegate
a sub-moderator? Signed messages that are checked by hand or otherwise
not reliably checked lose 99% of their virtue.
>
> My thought on that is not how by why...
I don't want to argue the fundamentals of trust design here.
>
> That's the job of bulk cancels, and for the most part there's no good
> way to do that now, and I don't find "not perfect solution to all
> possible problems" to be a compelling argument.
But if there is a nice solution to most of the problems, not just one of
them, and you're going halfway there, why wouldn't you do it?
>
> This is different from the situation today how? If the poster has old
> software there will be no cancel lock, therefore a locked cancel is not
> needed. Sites will or won't honor unsigned cancels just as they do now.
That doesn't follow. My take would be once there is an authenticated
cancel, sites that handle it would simply stop taking unath ones.
Now in an argument that works for both sides, if there is a signed cancel
available to the poster you can't assume that an article with no lock
can be cancelled with a regular cancel. You could assume that if there
is no signed cancel which is why it works both ways. But will there be
no signed cancel at all?
>
> What you are doing is defining the problem so only your solution fits.
Well, I'm not defining it, I hope I'm describing it. So go over my
list and let's see if everybody feels all those goals aren't worth it.