From: Brad Templeton (brad@templetons.com)
Date: Wed Oct 10 2001 - 15:13:32 CDT
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.)
>
> Cancel keys have the advantage of not requiring trust of any poster for
> more than that particular post. And as we both have noted it means you
> can't cancel a post which has expired (not a problem) and if the cancel
> arrives before the original post the information needs to be saved. But
> you noted this is low overhead, and I agree.
Cancel keys do have that advantage. As you will recall, when I first
proposed them, it was because we didn't have readily available libraries
to do public key crypto, so I searched for a way to do it without that.
However, that has changed. Mainly, I feel that because we are want to
build a public key system for authentication of spam cancel, newgroup and
moderators (and other things in the future) we should not build two
systems. The cancel locks have a number of significant disadvantages.
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.
So which is simpler, PK and CL or just PK?
> I agree, but it still requires a site to have trust for someone to
> cancel ANY post. That's not a bad thing, but I don't see why having
> cancel locks changes that:
> - sites w/o cancel lock implemented honor old cancels or don't
> - trusted moderator/nocem source MAY cancel anything at site option
> - poster and injector can cancel posts w/o requiring trust in general
As long as sites don't see it as a choice of implementing PK or CL. If
they do that, then CL is indeed simpler, but both end up ruined. Spammers
will put nonsense CLs on their spam, in the end forcing everybody to
implement PK, but with a lot of time lost because they imagined it to
be optional.
CLs only work for people who have new posting software. PK cancels work
for everybody, right away, which is a huge win as well.
>
> 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.
> > Sorry, I don't understand why being a uucp or satellite feed would
> > interfere with your ability to have a domain name or get a key for
> > one. Can you explain?
>
> It makes getting keys in real time a problem. And given the things which
> have happened recently, the Verisign/Microsoft fiasco and the
> possibility of enemy action, I'm even more disinclined to use CA.
There is no need to get keys in real time, so that is not an issue.
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.
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.
The world is full of weak security, and as long as the damage
is limited, it's how we like to live.
What if a CA has bad security? Then for a day some villain
gets to do some cancels or even a newgroup or post spam to
a moderated group. We've lived through that before.
c) In light of that, I recommend that coders make most actions
"undoable". An undo for most control messages isn't that
hard to code. An "uncancel" message makes some sense.
>
> > Huh? You mean in the original article? Then you have to wait for it
> > to authenticate the cancel.
>
> Agreed, but so what?
You were arguing against that.
>
> 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 it, it a nutshell. Now how people use the system is entirely up
to them. There will be times when they want to use it in a distributed
fashion, and times when they want to use it in a centralized fashion.
I think people will fine tune only to a certain level and then prefer to
delegate. Let 'em. My personal guess is that site admins might decide
to hand-tune which cancel streams they listen to, and they might join
optional hierarchies, hand installing who they trust to manage that
hierarchy.
But I know from practice that when it came to moderators, for example, site
admins quickly decided to let one authority manage the moderators file,
and ditto for newgroups.
It will end up in many ways like DNS. With DNS, in theory every site admin
can change their list of root servers, and indeed some have, but the
number of different lists is quite small. Most feel it is simpler to have
one set of roots rather than the chaos.
Likewise I don't think admins will want different groups saying who is
the moderator of what newsgroup. They will push instead for one system
to pick the moderator and trust one party or board to certify those
moderators, because that works and alternatives are unweildy.
However, my only goal -- a generalized system of delegating authority -- lets
you do it any way you want. I think it will gravitate to what people want
and what works.
>
> 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.
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.
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.
>
> 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.
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?
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? How to arrange for
keys to expire and be renewed? 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?
If you have a non-certificate based proposal to deal with these questions
then I would like to see it.
>
> Consider that "key server" can mean "CA master" and you see what I want
> to avoid.
You have some master one way or another. Either you download a list of
newgroup-blessed keys from Dave Lawrence as happens now, or you have a CA,
or you force every site to collect them manually and have no way to revoke
or change keys, or get a new key going quickly.
>
> That sounds as if every post would have to leave a trail of message-id
> and "real poster" information. Many sites don't know the real user on
> the server, they get it from the logs on the POP, or billing records, or
> whatever.
Then how do you plan to authenticate ordinary cancels with cancel locks?
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.
>
> > 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.
It is entirely the correct behaviour to send them a single e-mail asking
them to confirm the cancel, which they then reply to. It may not work all
the time (a cancelbot many not see their cancel, and if there are multiple
ones they must coordinate to avoid sending multiple challenges) but it's
certainly better than the cancel silently having no effect!
>
> Thank you for pointing out how complex your CA scheme would really be.
> Hopefully you have convinced people that cancel keys are the better way
> to go, and PGP signed nocem as is current practice.
You just keep saying this. Show us the alternative that's simpler and
solves the problems!
Trust me, I know it's non-trivial. But I have yet to see somebody propose
something simpler that actually does what we need.