Re: Supersedes and Expires

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

From: Henry Spencer (henry@spsystems.net)
Date: Wed Jul 01 1998 - 17:17:29 CDT


> > ...A specification which calls for network-wide use of
> > such technology, but invokes the Tooth Fairy to handle key distribution,
> > is a useless farce.
>
> The specification defines what the message format is. It does not call for
> network wide use...

Sure it does -- or is it your contention that USEFOR is not intended to
apply to Usenet?

> As I have seen others point out, this specification will
> cover non-USENET activities, and mandating that they all use the same key
> distribution system is silly.

Quite true. The point is not that everybody should be forced to use the
same key-distribution system, but that a key-distribution scheme capable
of handling worst-case requirements should *exist* before we publish a spec
that can't be implemented without one. Non-Usenet applications can always
use something else. (In fact, simple manual handling of key lists should
be viable in tightly-controlled private networks.)

What I object to is the attitude that we don't need to worry about it,
either it's somebody else's problem or it can be set aside until later --
even though it's vital to the authentication method we are proposing, and
nobody knows how to do it adequately in the Usenet environment. This is
perilously close to the sort of "nobody cares whether it's implementable"
idiocy that ISO is known for, which is utterly out of place in IETF.

> > ...Doing it manually -- which is essentially
> > how the moderator list is handled now -- won't work on this scale.
>
> Are there really more spam cancellers than moderators?

No, you've missed the point, although I plead guilty to stating it poorly.
The moderator list works because it's not all that important that each
site have a complete and current list. (Indeed, most sites that I'm
familiar with don't bother -- they just point moderated-group postings at
one of the big sites that maintains a full set of aliases.) Manual update
works for the moderators list only because it doesn't have to work very
well for that application. And on this scale -- the issue is number of
sites, not number of moderators -- manual update *doesn't* work very well.
That's fine for the moderators list, but useless for an application where
having correct, current, trustworthy information almost everywhere is really
important.

> > not happen by wishing for it, or by sweeping the problem under the rug in
> > hopes that somebody else will solve it.
>
> So we can't have a format for authenticated cancels until we have a proven
> key distribution system, and nobody will bother creating a proven key
> distribution system until there is a use for it. Catch 22. I guess it
> doesn't happen.

Not quite. What we want is not just a format for authenticated cancels,
but a design for an authenticated-cancel system. This is relevant here
because the system design dictates the format -- you can't devise a format
without having at least a general idea of how the system will work, and if
you haven't filled in the details, there is serious danger that the format
will be wrong or inadequate. We should not be trying to specify the
format without knowing what requirements it will have to satisfy.

And the key-distribution problem is central to the system design. It's
*not* a separate issue. A viable cancel-authentication system is maybe
10% authentication and 90% key distribution. Because of this, designing
such a system is harder than it looks.

It doesn't happen *unless* some of the people who dismiss key distribution
as a trivial issue that's not our problem -- even though we need it and
nobody knows exactly how to do it -- buckle down and solve it, in detail,
with careful attention to the real environment in which it will operate.
It shouldn't be impossible, but it requires effort, not just hand-waving.

                                                          Henry Spencer
                                                       henry@spsystems.net
                                                     (henry@zoo.toronto.edu)


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


This archive was generated by hypermail 2b29.