headers
Simon Lyall | 1 Jul 1998 01:01
Picon
Favicon
Gravatar

Authentication Std was: Supersedes and Expires

Just a note that Authentication is covered under our charter and if
someone wants to produce something as a seperate draft/standard aimed at
articles/mail messages they are welcome to do so in parallel with the main
Usefor Effort.

On Tue, 30 Jun 1998, Jacob Palme wrote:
> Strong cryptography, for some reason, tends to be so
> controversial that it is usually moved to separate future
> standards, which, for some reason, never tend to be
> finished. Probably the best way for the usefor document in
> general is the same, mention where strong crypthography
> would be useful, but leave the specification of it to a
> separate standard. That would help getting the new usefor
> standard ready in time. Then, of course,

--

-- 
Simon J. Lyall.  |   Very  Busy  |   Mail: simon <at> darkmere.gen.nz
"To stay awake all night adds a day to your life" - Stilgar | MT.
Permalink | Reply | 0 comments |
headers
John Stanley | 1 Jul 1998 02:18

Re: Supersedes and Expires


On Tue, 30 Jun 1998, Henry Spencer wrote:

> I don't believe the validity of my comments is significantly changed if you
> strike out "useless" and replace it with "of very marginal utility".  The
> main point of a cancel-authentication system, surely, is to reject forged
> cancels, which are a much bigger problem than occasional intolerance of
> legitimate ones.  (At least, it seems that way to me.)

That depends on how you view a cancel-authentication system. If you start
from a position that ALL cancels are invalid until proven otherwise, then
the main point of a cancel-authenticatioon system is not to reject forged
cancels but detect authorized ones. Opt-in versus opt-out, so to speak. 

> > Spam cancellers. Hmmm. The H(H()) paradigm falls apart since there is no
> > secret they have inserted into the article. However, the same "authority"
> > that put the spam canceller on the approved list can also include a public
> > key, which along with the canceller including the encrypted "variable"
> > in the cancel, can demonstrate that the canceller is on the approved list.
> 
> Who is the "authority"?  How is that "approved list" managed and updated? 

I consider that this falls outside the scope of a document that is
intended to standardize message format. This would be something that would
be decided on a hierarchy basis. I don't believe that the list of
moderators is part of RFC 1036, yet somehow there is a list of moderator
addresses maintained. Whether that method would work for this requirement
or not, I don't know.

> Once it's involved in authentication, suddenly it becomes very important
(Continue reading)

Permalink | Reply | 5 comments |
headers
John Stanley | 1 Jul 1998 02:42

Re: Supersedes and Expires


On 30 Jun 1998, Andrew Gierth wrote:

> There are loads of other legitimate examples. Don't forget that rules
> change across hierarchies; you cannot generalise the big-8's tight
> rules on cancels into a restriction at the transport level without
> causing major problems for other hierarchies.
> 
> Examples:
> 
>   - users cancelling forgeries of their addresses

Yes, this is one that I certainly did forget. My reaction to this would be
to use a public key crypto system in a similar manner as the spam
canceller authentication I mentioned. However, you then have question of
how to distribute the public key, and how to prevent bad guys from
registering public keys in your name before you know you should do it. 

>   - moderators cancelling forgeries of their approval

This would be covered by authenticated posting for moderators. There would
be no forgeries to cancel.

>   - retromoderation (yes, in some hierarchies this *is* legitimate)

If a retroactive moderator is official, then his authentication would be
on a par with spam cancellors and his credentials would be distributed in
a similar manner.

>   - hierarchy enforcement (e.g. net-monitor, bofh-bot, etc.)
(Continue reading)

Permalink | Reply | 11 comments |
headers
Henry Spencer | 1 Jul 1998 03:21

Re: Supersedes and Expires

> > Who is the "authority"?  How is that "approved list" managed and updated? 
> 
> I consider that this falls outside the scope of a document that is
> intended to standardize message format...

No, sorry, speaking as someone who has altogether too much involvement
right now with encryption and authentication technology, key distribution
is most definitely an integral part of any such system.  The system is
useless without it.  A specification which calls for network-wide use of
such technology, but invokes the Tooth Fairy to handle key distribution,
is a useless farce.

> > Once it's involved in authentication, suddenly it becomes very important
> > that the list is kept current and is itself carefully authenticated...
> 
> Yes, I agree. 

Note, however, that this means that it is *automatically* kept current and
*automatically* carefully authenticated.  Doing it manually -- which is
essentially how the moderator list is handled now -- won't work on this
scale.  Again, you can't just invoke the Tooth Fairy here; the techniques
for doing it have to be spelled out in detail, and they must be workable. 
The technology isn't usable until this problem is solved and solved well. 

If every site, or even many sites, are to be doing authentication, then
they must all have a current, reliable copy of that list, and this will
not happen by wishing for it, or by sweeping the problem under the rug in
hopes that somebody else will solve it. 

                                                          Henry Spencer
(Continue reading)

Permalink | Reply | 4 comments |
headers
Russ Allbery | 1 Jul 1998 04:44
Picon
Favicon
Gravatar

Re: Supersedes and Expires

John Stanley <stanley <at> PEAK.ORG> writes:

> Yes, this is one that I certainly did forget. My reaction to this would
> be to use a public key crypto system in a similar manner as the spam
> canceller authentication I mentioned. However, you then have question of
> how to distribute the public key, and how to prevent bad guys from
> registering public keys in your name before you know you should do it.

There was some discussion a while back about ways of addressing this, but
they all basically required a centralized post checker that would issue
cancels under its own authentication, which would then be authorized via
the same means as spam cancels.  One of the drawbacks of that approach,
though, is that one needed a way of authenticating posts, which in
practice required PGP signatures or something equally heavy-weight, unless
one was willing to go with possibly forgeable heuristics.

--

-- 
Russ Allbery (rra <at> stanford.edu)         <URL:http://www.eyrie.org/~eagle/>
Permalink | Reply | 10 comments |
headers
Russ Allbery | 1 Jul 1998 05:05
Picon
Favicon
Gravatar

Re: Supersedes and Expires

Henry Spencer <henry <at> spsystems.net> writes:

> Note, however, that this means that it is *automatically* kept current
> and *automatically* carefully authenticated.  Doing it manually -- which
> is essentially how the moderator list is handled now -- won't work on
> this scale.  Again, you can't just invoke the Tooth Fairy here; the
> techniques for doing it have to be spelled out in detail, and they must
> be workable.  The technology isn't usable until this problem is solved
> and solved well.

The way in which the moderator submission list is currently being handled
actually generalizes to authorizing spam cancels as follows:  Pick one
person/organization/repository as a top-level certifying agency, and then
have them decide who is trusted as a spam canceller and sign those
people's keys.  Then you either set up a central key distribution system
where keys can be periodically retrieved, or you include the complete key
trace back to the certifier in the signature a la S/MIME.

Now the notion of any kind of central authority for spam cancelling I
realize causes a lot of screaming, worries about legal threats, and the
like, for very good reasons.  But we should probably keep in mind that
even a solution that doesn't scale to the Big Eight and/or alt.* may be
very useful for smaller hierarchies (for example, I don't think the biz.*
hierarchy would have much difficulty picking a spam cancel certification
authority).

This sort of system *would* scale (see Verasign for evidence) and *would*
be directly analogous to the way that moderation relaying is currently
handled, even if it wouldn't be workable for all cases.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 1 Jul 1998 11:29
Picon
Picon

Re: Supersedes and Expires

In <87ww9zulr7.fsf <at> erlenstar.demon.co.uk> Andrew Gierth <andrew <at> erlenstar.demon.co.uk> writes:

>It's not quite as clear-cut as you might think; current usage of
>NoCeM-on-spool is not friendly to partial feeds (a site that doesn't
>take alt.sex.* and alt.binaries.* will be carrying an awful lot of
>traffic in news.lists.filters that doesn't apply to it).

I think that could be solved by a better structuring of how the lists are
published, such as sub-hierarchies of news.lists.filters, or bots running
on well connected sites that constructed useful abstracts for distribution
by other means.

BTW, the same problem already exists for conventional cancels for some
people. If you are on a partial "suck" feed (I am), then the only way you
get to see cancels is by taking the full control "hierarchy" (I did it
once, by accident :-( ). Fortunately, in my case, my upstream has already
done most of the cancelling.

>Examples:

>  - users cancelling forgeries of their addresses
>  - moderators cancelling forgeries of their approval
>  - retromoderation (yes, in some hierarchies this *is* legitimate)
>  - hierarchy enforcement (e.g. net-monitor, bofh-bot, etc.)

I think we require 3rd party cancels to be "authenticated" (I think anyone
noteworthy enough to be forged will be net-savvy enough to have a
signature key, and certainly the other categories you mention will).

A site receiving such a cancel has 3 options:
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Stanley | 1 Jul 1998 21:14

Re: Supersedes and Expires


On Tue, 30 Jun 1998, Henry Spencer wrote:

> > > Who is the "authority"?  How is that "approved list" managed and updated? 
> > 
> > I consider that this falls outside the scope of a document that is
> > intended to standardize message format...
> 
> No, sorry, speaking as someone who has altogether too much involvement
> right now with encryption and authentication technology, key distribution
> is most definitely an integral part of any such system.  The system is
> useless without it.  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. 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.

> Note, however, that this means that it is *automatically* kept current and
> *automatically* carefully authenticated.  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?

> If every site, or even many sites, are to be doing authentication, then
> they must all have a current, reliable copy of that list, and this will
> not happen by wishing for it, or by sweeping the problem under the rug in
(Continue reading)

Permalink | Reply | 2 comments |
headers
John Stanley | 1 Jul 1998 21:22

Re: Supersedes and Expires


On 30 Jun 1998, Russ Allbery wrote:

> There was some discussion a while back about ways of addressing this, but
> they all basically required a centralized post checker that would issue
> cancels under its own authentication, which would then be authorized via
> the same means as spam cancels.  One of the drawbacks of that approach,
> though, is that one needed a way of authenticating posts, which in
> practice required PGP signatures or something equally heavy-weight, unless
> one was willing to go with possibly forgeable heuristics.

The main drawback to using PGP, and the associated existing key
registries, is that you add step one to the forger's operation: submit a
public key to the registry using the victim's id.

Perhaps a better alternative is to add the key registry function to the
news server. If you allow people to post using your news server, you also
allow them to register keys. Then an authenticated cancel is verified
using the sender's key obtained from the original article's news server.
That still has the same problem, though, doesn't it, although the forger
would have to connect to the server from a posting ok host.
Permalink | Reply | 9 comments |
headers
Henry Spencer | 2 Jul 1998 00:17

Re: Supersedes and Expires

> > ...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.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane