headers
Charles Lindsey | 2 Sep 2001 14:58
Picon
Picon

Straw Poll on mvgroup

I think we have discussed this as much as is useful to make up our minds.
It is clear that implementation problems in INN mean we do not press the
automatic redirection from oldgroup to newgroup too hard (a 'MAY' or a
'should' is as far as we should go). We are agreed that 'mvgrp
old.hierarchy.* new.hierarchy.*'  is OUT.

What is not clear is whether to proceed with a cut down version, or leave
it out altogether. People asked for other implementors to be consulted,
which we did; but only two replied, and they seemed to be somewhat
atypical. Nevertheless, people have continued to make constructive
contributions on various details.

So I think a straw poll is needed. The proposal as it stands is the
following:

1. 'mvgroup' does at least the same as 'newgroup'.

2. In addition, it SHOULD prevent injection of new articles to oldgroup (at
servers that honour it at all, of course).

3. It SHOULD result in a delayed 'rmgroup' (Curt wanted that down to MAY,
but Clive seeed happy with SHOULD - it could be discussed further).

4. Servers MAY redirect articles from oldgroup so that their users see
them in newgroup. That might or might not include articles already
received before the mvgroup.

5. If (4) is done, headers (esp. Newsgroups) MUST NOT be changed, except
for Xref (for which servers may do whatever they think is best - either
oldgroup or newgroup or both).
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ralph Babel | 3 Sep 2001 14:42
Picon

Re: Straw Poll on mvgroup

Charles Lindsey wrote:

> Please Vote *by email*.

What else? After all, this is a _mail_ing-list, isn't it?

> YES or NO.

NO.
Permalink | Reply | 0 comments |
headers
Clive D.W. Feather | 4 Sep 2001 00:43

Re: Straw Poll on mvgroup

Charles Lindsey said:
> So I think a straw poll is needed. The proposal as it stands is the
> following:
[...]
> Please Vote *by email*. YES or NO.

YES.

--

-- 
Clive D.W. Feather  | Work:  <clive <at> demon.net>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <clive <at> davros.org>  | Fax:  +44 20 8371 1037
Demon Internet      | WWW: http://www.davros.org | DFax: +44 20 8371 4037
Thus plc            |                            | Mobile: +44 7973 377646
Permalink | Reply | 0 comments |
headers
Charles Lindsey | 4 Sep 2001 11:42
Picon
Picon

Signed Headers in Mail and Netnews

In between working on other things, I have gradually been tidying up
the header signing draft. We last discussed this nearly a year ago and
agreed various changes, and decided to shelve it while we got on with
other things. I have now put up a new draft
	draft-lindsey-usefor-signed-01.txt
which you will find on the Landfield site or (soon) the IETF internet
drafts site. It incorporates all the changes we agreed, plus general
tidyings.

Whilst I would be happy to discuss any points people want to raise on
this list, I don't think we want to discuss it in detail just at this
point in time.

However, our next job is to look at various security (cancel, etc) loose
ends that need to be tidied up in our draft (I shall post a list of
issues and possibilities as my next job), so the signing draft is now
there if it turns out to be needed.

Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> clw.cs.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
Permalink | Reply | 0 comments |
headers
Kai Henningsen | 4 Sep 2001 12:13
Picon

Re: Straw Poll on mvgroup

Hi Charles,
chl <at> clw.cs.man.ac.uk (Charles Lindsey)  wrote on 02.09.01 in <GJ1DDx.Ey8 <at> clw.cs.man.ac.uk>:

> 1. 'mvgroup' does at least the same as 'newgroup'.
>
> 2. In addition, it SHOULD prevent injection of new articles to oldgroup (at
> servers that honour it at all, of course).
>
> 3. It SHOULD result in a delayed 'rmgroup' (Curt wanted that down to MAY,
> but Clive seeed happy with SHOULD - it could be discussed further).

MAY or SHOULD NOT; hierarchy admins should send rmgroups as usual.

> 4. Servers MAY redirect articles from oldgroup so that their users see
> them in newgroup. That might or might not include articles already
> received before the mvgroup.
>
> 5. If (4) is done, headers (esp. Newsgroups) MUST NOT be changed, except
> for Xref (for which servers may do whatever they think is best - either
> oldgroup or newgroup or both).

YES.

MfG Kai
Permalink | Reply | 0 comments |
headers
Charles Lindsey | 4 Sep 2001 13:54
Picon
Picon

Security, Cancels and Authorization

The story so far:

1. Cancels

It must be nearly two years since we last discussed these. We knowingly
left them in an incomplete state, with the intention of returning to
them 'later'. I think 'later' is now 'now'. Various pseudo-comments in
the draft indicate where we left off.

Particular issues are Cancel-Locks, multiple cancels in one message, and
authentication of 3rd party cancels.

2. Digital signatures

We discussed this about a year ago, but decided to defer further
consideration of it. We did agree many changes to the draft I had
produced, and I have now produced a new draft incorporating those
changes, so it is there if it is needed.

3. Loose ends in the draft

The draft contains a few mentions of digital signatures of headers in
its official texts, and rather more mentions in pseudo comments, where
more explicit mentions could be made if we had something more definite
to say.

I have now gone through the draft and extracted the parts that seem
relevant to these issues. They are attached to this message.

What to do next? I see the following possibilities:
(Continue reading)

Permalink | Reply | 5 comments |
headers
Bill Davidsen | 4 Sep 2001 23:49
Picon
Favicon

Re: Security, Cancels and Authorization

Charles Lindsey <chl <at> clw.cs.man.ac.uk> wrote:

> What to do next? I see the following possibilities:
> 
> 1. The BIG BIG solution
> 
> Complete the work on Digital Header Signatures, and incorporate it
> into the draft as the approved method (or, more likely, put it into a
> separate RFC and refer to it in the draft).
> 
> I don't somehow feel that this WG wants to follow that Path at the
> moment, though Brad will surely complain loudly that we will have failed
> in our purpose if we do not. And he would rightly point out that out
> charter identifies standards for the signing of articles as needing
> "urgent attention".

  Speaking for only myself, I would love to put this in a separate RFC
and move forward. We make no progress by revisiting the issue, there is
not even complete agreement on what should be done, there is one camp
which wants to stick with a technology which has a track record (PGP)
and another which wants to use some theoretically better method which
introduces single point of failure and/or multiple conflicting
certificate type information.

  The devil is in the details, and I don't think there's much likelyhood
that we will agree any better now than we did, possibly less, since all
of us have had a chance to learn more about the failure modes of various
methods.

  Let's move forward and get what we have out, with a reference to a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Clive D. W. Feather | 5 Sep 2001 15:50
Picon
Picon

Re: Security, Cancels and Authorization


In message <200109041154.MAA01837 <at> clw.cs.man.ac.uk>, Charles Lindsey 
<chl <at> clw.cs.man.ac.uk> writes
>1. The BIG BIG solution
>
>Complete the work on Digital Header Signatures, and incorporate it
>into the draft as the approved method (or, more likely, put it into a
>separate RFC and refer to it in the draft).

I agree with Bill - while it would be nice, I can't see this happening 
in the right timescales.

>OTOH, we might well agree that an early extension to cover such security
>issues would be the way to proceed.

I would like to go further, and see work start *RIGHT NOW* on the 
security document (whether on this list or a separate one). At the point 
that we're making a final pass on the main draft, we can see whether the 
security stuff is in a good enough state to merge in.

>2. The SMALL SMALL solution
>
>Do nothing.

No.

>3. The MIDDLE way
>
>Well there are several Middle ways possible, but one possibility would
>be to indicate that a further RFC on Security Issues was to follow, and
(Continue reading)

Permalink | Reply | 3 comments |
headers
Charles Lindsey | 6 Sep 2001 16:08
Picon
Picon

Re: Security, Cancels and Authorization

In <tLSJhXHR2il7EwZP <at> on-the-train.demon.co.uk> "Clive D. W. Feather"
<clive <at> on-the-train.demon.co.uk> writes:

>In message <200109041154.MAA01837 <at> clw.cs.man.ac.uk>, Charles Lindsey 
><chl <at> clw.cs.man.ac.uk> writes

>>I think the main issues with regard to cancels are concerned with
>>multiple cancels.

>I think this is something we *should* solve in the main document, right 
>now. Whether it's a block cancel or a NOCEM, don't worry about security 
>- it should and will use the same security mechanism as a single cancel 
>does.

Well let us at least gather some issues together regarding multiple cancels.

Q1. Is is the case that typical spews and spams get posted over relatively
short timescales, so that the canceller/nocemer is in a position to grab
the whole batch and deal with it as a single entity?

My observation of some recent Hipcrime episodes seems to indicate that he
tended to put out a large spew, taking maybe half an hour. And then he
took some time off while he morphed to a slightly different spew, and then
sent that one out (though sometimes he did seem to have two versions on the
go simultaneously).

Q2. Do cancellers try to catch a spew in real time, issuing cancels as
fast as articles arrive (so that hopefully they arrive at sites before the
cancelled articles)? Looking at some recent cancels by Andrew, it seemed
that the cancel was issued typically one hour to three hours later than
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andrew Gierth | 6 Sep 2001 19:15
Picon
Picon

Re: Security, Cancels and Authorization

>>>>> "Charles" == Charles Lindsey <chl <at> clw.cs.man.ac.uk> writes:

 Charles> Well let us at least gather some issues together regarding multiple cancels.

 Charles> Q1. Is is the case that typical spews and spams get posted
 Charles> over relatively short timescales, so that the
 Charles> canceller/nocemer is in a position to grab the whole batch
 Charles> and deal with it as a single entity?
 [...]

"It depends".

 Charles> Q2. Do cancellers try to catch a spew in real time, issuing
 Charles> cancels as fast as articles arrive (so that hopefully they
 Charles> arrive at sites before the cancelled articles)? Looking at
 Charles> some recent cancels by Andrew, it seemed that the cancel was
 Charles> issued typically one hour to three hours later than the
 Charles> spam, which does not seem like a real time operation.

At the moment that may be mostly backlog (incoming delays to the server
that feeds the bot, which is getting a little long in the tooth now).
I have a faster bot for dealing with the flooding incidents.

My cancels are of three kinds:
 1) auto-cancels for ongoing incidents, which are issued as articles arrive
 2) cancels for auto-detected binary spams, which are issued in batches at
    the point where the accumulated BI reaches 20, and may include articles
    up to 10 hours or so old
 3) manually generated cancels (which may be for articles of any age, but
    not usually more than a few days, and are usually generated in batches)
(Continue reading)

Permalink | Reply | 1 comment |

Gmane