From: Bill Davidsen (davidsen@prodigy.com)
Date: Thu Oct 11 2001 - 09:46:20 CDT
Brad Templeton <brad@templetons.com> wrote:
> On Wed, Oct 10, 2001 at 11:00:13AM -0400, Bill Davidsen wrote:
> > > I've answered this so many times, I am surprised you've missed it.
> > > The keys are in certificates, they are included with the article itself.
> > > All you need to install (or in fact all your news software author includes
> > > if you trust him or her) is the set of root CA keys you wish to trust.
> >
> > But that identifies the person sending the cancel, not their authority
> > to do it... It means I have to trust someone to issue cancels in certain
> > cases. Now that's fine for moderators, although I'm not sure that
> > signing every post is a bad thing either, which would let forged posts
> > be rejected upstream by some (eventually most) hosts.
>
> No, as I have been writing, the certificate doesn't need to identify the
> sender, just that there is a chain of trust from you to the sender
> authorizing whatever it is the article wants to do (cancel, moderated group
> posting, newgroup etc.)
You're splitting hairs... it identified the sender as a trusted person
*in general* rather than just for a single post.
> Of the two main advantages, one is simplicity, but that's not relevant since
> we are not choosing between two systems (in which case we would indeed like
> a simpler one) but instead choosing whether to build PK and CL or just PK.
>
> The other main advantage -- no need for 3rd party certifiers, is strong but
> is also a disadvantage, which has led some people to suggest that the
> poster, the poster's injector, the moderator and the moderator's injector all
> might end up putting cancel locks on an article in the extreme case. And
> if they don't, they can't cancel -- unless of course the PK system is there.
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.
> So which is simpler, PK and CL or just PK?
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.
> CLs only work for people who have new posting software. PK cancels work
> for everybody, right away, which is a huge win as well.
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.
> >
> > I don't see this as either/or, a cancel locked post SHOULD not be
> > canceled by an old style cancel. Site MAY allow OOB cancels like nocem.
>
> That's exactly the problem. You can bet the first users of the cancel
> lock field will be the spammers.
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.
The chances that some site would put in CL and not have another cancel
method in place are pretty remote. Site who care about spam usually have
filters and some form of cancel.
> As for CAs making mistakes -- of course they will, lots of them. However,
> this issue is dealt with in several ways:
>
> a) There are of course control messages to immediately revoke
> bad certificates.
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.
> b) Today on USENET we have three choices -- trust everybody (as
> we do with Approved headers), trust nobody (as sites that have
> turned off cancel, or put in filters have done) or trust only
> articles signed with keys that were hand installed (as is the
> case for pgpverify and some nocem.) Even a system of basic
> trust full of holes is better than the first two choices, and
> the latter choice doesn't scale.
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.
> > You see a trusted central authority as a good thing, I don't. It's a
> > single point of failure and compromise, and would probably not scale
> > well if it were giving out thousands of certificates. Not to mention
> > that it might cost more than people would want to donate.
>
> 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.
> > I don't see that the methods "compete," one validates cancels for a
> > given article, one validates the right of a given poster to cancel any
> > post (or a subset of posts, whatever).
>
> They compete in that if you have a PK system, you would of course have
> a PK signed cancel, available not just to spam cancellers but to site admins,
> moderators, individual posters and special cancelbots.
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.
> Individual posters would want to use the PK signed cancels not by getting
> their own keys, but by challenge/response to a cancelbot, or through their
> own site's injector.
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.
> As such they compete, as two ways to cancel an article. The CL requries you
> insert the lock when you posted the original. PK cancels require no change
> to the original article.
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.
> >
> > No, I make the assumption that some other people share my distrust of CA
> > vs. PGP (or similar) keys.
>
> Perhaps, but I really would like to see a workable proposal, that scales,
> that does't use certificates. I (and pretty much the entire crytpo
> community) view certificates as following Einstein's dictate to make everything
> as simple as possible but no simpler.
I view them as the best solution to the wrong problem. They only address
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.
> If there aren't certificates, site admins must manually configure the keys
> they will trust. Do you really have a model for how that would scale?
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.
In other words you are trying to find the best way to do something which
need not be done.
> How we could get the keys for many hundreds of moderators installed? How
> we could get them installed immediately at hundreds of thousands of sites
> when a new moderated group is created? How we would deal with an involuntary
> change of moderators? How we would deal with a trusted person's key being
> compromised or a trusted person becoming untrusted?
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).
> How to arrange for
> keys to expire and be renewed?
My thought on that is not how by why...
> How sites might cancel a spam that
> pretends to be from their site and is causing hate mail to pour into
> their abuse address? How a user might do that to a forgery?
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.
> Most people have been advocating that injectors will add locks, and
> add unlocks for local cancels after authenticating the user. At that
> point whether they issue a PK signed cancel or a CL signed cancel is
> the same.
No it's not, but I can't find a way to get you to even see the
difference. A CL proves authority over a single message, no trust
required (trusted the way you use it is a technical term, not an actual
fact).
> > > 2) For users who don't have a new injector, the cancel goes out the old
> > > way. The cancelbot notices it, and sends back a challenge to the poster.
> > > The poster responds and the cancelbot issues a signed cancel.
> >
> > You're not serious, are you? You're just making up the most cumbersome
> > way to possibly implement this? What a great argument for cancel keys.
>
> Completely serious. Tell me what you dislike about this plan. Remember,
> this is for users with old software and old injectors. If they issue
> their old cancel, it will simply be ignored at most sites, including all
> sites insisting on signed cancels.
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.
> You just keep saying this. Show us the alternative that's simpler and
> solves the problems!
What you are doing is defining the problem so only your solution fits.
The simpler solution is to stop trying to make "trust" fit and go with a
solution for individual cancels, and another solution for trust. And
once you do that, you reduce the keys to a handful and eliminate the
lovely key management, trust inheritance, heirarchical certification,
diddlyfiddle and replace it with one trusted source for moderator keys,
and a few selected spambots. Since more of either is not "better" there
is no scaling problem.
Certificates are an elegant solution, but to another problem.
-- -bill davidsen (davidsen@prodigy.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me