From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Tue Sep 04 2001 - 06:54:40 CDT
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:
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".
OTOH, we might well agree that an early extension to cover such security
issues would be the way to proceed.
2. The SMALL SMALL solution
Do nothing. Leave the draft exactly as it is. But this would leave
various inconsistences and hanging issues (like we tell people that they
SHOULD take steps to verify things, but do not say how). So we would at
least have to paper over those cracks with suitable wording.
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
to write wording into the draft at various points indicating that it
should be used at those points as soon as it is available.
However, if we are to do that, then we need to have in mind a broad
outline of what it would cover, so as to be sure not to put anything
into the present draft that might make it difficult later on. Also, if
there was any plan to change or augment any of the existing headers (I
have cancels principally in mind) then it might be better to do it now.
Server implementors are not going to take kindly to further changes in
basic headers if they have just finished upgrading their systems to be
in line with our first standard.
I think the main issues with regard to cancels are concerned with
multiple cancels. Currently, the bandwidth and CPU resources consumed
by issuing a separate cancel for each spam/spew article are quite
significant.
Possible solutions that have been suggested:
1. Allow a whole list of articles to be cancelled to be included in the
one Control: cancel header. This was already in son-of-1036, I believe,
and CNews implements it. Do any other systems accept it? Are there any
implementation difficulties?
2. Invent a separate "block cancel" header with the list of articles in
the body. That might mean more implementation effort for server-writers,
but it seemed the preferred solution last time we discussed it. The
NOCEM syntax might be suitable.
3. Encourgae NOCEM with "cancel on spool" as the preferred way of
dealing with spam, rather than the use of cancels. This might mean
writing a MOCEM RFC, which might be a good idea anyway.
See the text of the present Cancel draft for other issues needing attention.
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@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
6.14. Approved
The Approved header indicates the mailing addresses (and possibly the
full names) of the persons or entities approving the article for
posting.
Approved-content = From-content ; see 5.2
Each mailbox contained in the Approved-content MUST be that of the
person or entity in question, and one of those mailboxes MUST be that
of the actual injector of the article.
[This is the start of an attempt to strengthen this header. It should be
a TOSSable offence to put a dummy or invalid address in here. Later,
when we have some form of authentication, I would hope to be able to say
more.]
An Approved header is required in all postings to moderated
newsgroups. If this header is not present in such postings, then
relaying and serving agents MUST reject the article. Please see
section 8.2.2 for how injecting agents should treat postings to
moderated groups that do not contain this header.
An Approved header is also required in certain control messages, to
reduce the risk of accidental posting of same; see the relevant parts
of section 7.
7. Control Messages
The following sections document the control messages. "Message" is
used herein as a synonym for "article" unless context indicates
otherwise. Group control messages are the sub-class of control
messages that request some update to the configuration of the groups
known to a serving agent, namely "newgroup". "rmgroup", "mvgroup"
and "checkgroups", plus any others created by extensions to this
standard.
All of the group control messages MUST have an Approved header
(6.14). Moreover, in those hierarchies where appropriate
administrative agencies exist (see 1.1), group control messages Ought
Not to be issued except as authorized by those agencies.
[They SHOULD also use one of the authentication mechanisms which we may
define when we get a Round Tuit.]
The Newsgroups header of each control message SHOULD include the
newsgroup-name(s) for the group(s) affected (i.e. groups to be
created, modified or removed, or containing articles to be canceled).
This is to ensure that the message progagates to all sites which
receive (or would receive) that group(s). It MAY include other
newsgroup-names so as to improve propagation (but this practice may
cause the control message to propagate also to places where it is
unwanted, so it should not be used without good reason).
For convenience, the descriptions below are phrased on the assumption
that control messages will be honoured by sites receiving them.
Naturally, this does not apply where they have not been issued by the
appropriate administrative agencies (and sites SHOULD take such steps
as are reasonably practicable to validate their authenticity).
Moreover, acceptance of such messages MAY be subject to local
administrative restrictions, and MAY be denied or referred to an
administrator for approval (either as a class or on a case-by-case
basis). Analogously, where the description below specifies that a
message or portion thereof is to be ignored, this action MAY include
reporting it to an administrator.
Relaying Agents MUST propagate even control messages that they do not
understand.
In the following sections, each type of control message is defined
syntactically by defining its verb, its arguments, and possibly its
body.
7.5. Cancel
The cancel message requests that a target article be "canceled" i.e.
be withdrawn from circulation or access. A cancel message may be
issued in the following circumstances.
1. The poster of an article (or, more specifically, any entity
mentioned in the From header or the Sender header, whether or not
that entity was the actual poster) is always entitled to issue a
cancel message for that article, and serving agents SHOULD honour
such requests. Posting agents SHOULD facilitate the issuing of
cancel messages by posters fulfilling these criteria.
2. The agent which injected the article onto the network (more
specifically, the entity identified by the path-identity in front
of the leftmost '%' delimeter in the Path header (5.6) or in the
Injector-Info header (6.19) and, where appropriate, the moderator
(more specifically, any entity mentioned in the Approved header)
is always entitled to issue a cancel message for that article, and
serving agents SHOULD honour such requests.
3. Other entities MAY be entitled to issue a cancel message for that
article, in circumstances where established policy for any
hierarchy or group in the Newsgroup header, or established custom
within Usenet, so allows (such policies and customs are not
defined by this standard). Such cancel messages MUST include an
Approved header identifying the responsible entity. Serving agents
MAY honour such requests, but SHOULD first take steps to verify
their appropriateness.
[I think that accords with the accepted norms for 1st, 2nd and 3rd party
cancels (or is a moderator a 1st party?). Observe the use of an Approved
header in place of the present X-Cancelled-By (I cannot see that we need
a new header for that when Approved is available). The definitions given
are sufficient to establish which category a cancel was in, assuming
that nobody told any lies, and to establish who had committed abuse
otherwise. So far so good, but we now need authentication methods on top
of all that.]
[A future draft of this standard may contain provisions for a Cancel-
Lock header to enable verification of the authenticity of 1st (and even
2nd) party cancels, and means for digital signatures to establish the
authenticity of 3rd party cancels.]
[A future draft of this standard may also contain provision for a "block
cancel" message, with a list of messages to be canceled contained in its
body rather than in the headers. Whether this needs to have a Control
header at all, and whether the existing "nocem-on-spool" is adequate for
this purpose, and indeed whether NOCEM as such should be part of this,
or some other, standard are issues that are yet to be addressed.]
cancel-verb = "cancel"
cancel-arguments = CFWS message-id
The argument identifies the article to be cancelled by its message
identifier. The body SHOULD contain an indication of why the
cancellation was requested. The cancel message SHOULD be posted to
the same newsgroup(s), with the same distribution(s), as the article
it is attempting to cancel.
A serving agent that elects to honour a cancel message SHOULD delete
the target article completely and immediately (or at the minimum make
the article unavailable for relaying or serving) and also SHOULD
reject any copies of this article that appear subsequently. See also
sections 8.3 and 8.4.
NOTE: The former requirement [RFC 1036] that the From and/or
Sender headers of the cancel message should match those of the
original article has been removed from this standard, since it
only encouraged cancel issuers to conceal their true identity,
and it was not usually checked or enforced by canceling
software. Therefore, both the From and/or Sender headers and
any Approved header should now relate to the entity responsible
for issuing the cancel message.
8.7. Duties of a Moderator
A Moderator receives news articles by email, decides whether to
accept them and, if so, either injects them into the news stream or
forwards them to further moderators.
A moderator processes an article, as submitted to any newsgroup that
he moderates, as follows:
1. He decides, on the basis of whatever moderation policy applies to
his group, whether to accept or reject the article. He MAY do this
manually, or else partially or wholly with the aid of appropriate
software for whose operation he is then responsible. He MAY modify
the article if that is in accordance with the applicable
moderation policy (and in particular he MAY remove redundant
headers and add Comments and other informational headers). He MAY
inform the poster as to whether the article has been accepted or
rejected.
If the article is rejected, then it fails for all the newsgroups
for which it was intended (in particular the moderator SHOULD NOT
resubmit the article, with a reduced Newsgroups header, to any
remaining groups, especially if this will break any authentication
checks present in the article). If the article is accepted, the
moderator proceeds with the following steps.
..............................
3. He adds an Approved header (6.14) containing a mailbox identifying
himself (or, if the article already contains an Approved header
from another moderator, he adds that identifying information to
it). He MAY also add further headers to authenticate that the
article has been properly approved.
[That can be strengthened when we have defined proper authentication
mechanisms.]
..............................
9.2.2. Compromise of System Integrity
The posting of unauthorized (as determined by the policies of the
relevant hierarchy) control messages can cause unwanted newsgroups to
be created, or wanted ones removed, from serving agents.
Administrators of such agents SHOULD therefore take steps to verify
the genuiness of such control messages, either by manual inspection
(particularly of the Approved header) or by checking any digital
signatures that may be provided. In addition, they SHOULD
periodically compare the newsgroups carried against any regularly
issued checkgroups messages, or against lists maintained by trusted
servers and accessed by out-of-band protocols such as FTP or HTTP.
Malicious cancel messages (7.5) can cause valid articles to be
removed from serving agents. Administrators of such agents SHOULD
therefore take steps to verify that they originated from the poster,
the injector or the moderator of the article, or that in other cases
they came from a place that is trusted to work within established
policies and customs. Articles containing Replaces and/or Supersedes
headers (6.15) are effectively cancel messages, and SHOULD be subject
to the same checks. Currently, many sites choose to ignore all
cancel messages on account of the difficulty of conducting such
checks.
[But we cannot really say much more until we have Cancel Locks and
digital signatures in place.]
Improperly configured serving agents can allow articles posted to
moderated groups onto the net without first being approved by the
moderator. Injecting agents SHOULD verify that moderated articles
were received from one of the entities given in their Approved
headers and/or check any digital signatures that may be provided.
..............................