A way to deal with Supersedes: (was Re; Cat bathing)
Matt Dillon
What we do is require that the control message for any article being
canceled or any article containing a supersedes have an X-Trace: header.
The first element of the X-Trace: header must match one of the Path:
elements of the article being canceled or superseded.
Presumably, the 'official' cancel generators either have a separate
propogation mechanism for their cancels, or have direct access to a
news transit box and can synthesize a matching X-Trace: header.
We then pound all the NNTP software makers to either generate X-Trace:,
or to prevent a POST command from being able to synthesize its own
X-Trace:. A job that should be relatively easy.
I like this a whole lot better then Cancel-Lock:, which is a really stupid
idea in my view.
-Matt
:From wlev...@ix.netcom.com Sat Oct 24 12:49:22 PDT 1998
:Article: 43195 of news.software.nntp
:Path: news3.best.com!news1.best.com!su-news-hub1.bbnplanet.com!news.gtei.net!newsfeed.direct.ca!news.insinc.net!stimpy.cal.sfl.net!thor.cal.sfl.net!198.161.101.38!cyberhighway.net!bstkt
:Message-ID: <2lCwQtcigQU.QFs...@cyberhighway.net>
:Supersedes: <362A8CE8...@cyberhighway.net>
:Subject: Cat bathing
:From: Ruth <bs...@cyberhighway.net>
:Approved: wlev...@ix.netcom.com (William A. Levinson)
:Newsgroups: alt.gothic,news.test,news.software.nntp,alt.horror.werewolves,rec.pets
:Reply-to: wlev...@ix.netcom.com (William A. Levinson)
:Lines: 77
:Date: 24 Oct 1998 09:43:55 GMT
:NNTP-Posting-Host: 198.161.101.38
:X-Trace: thor.cal.sfl.net 909246197 198.161.101.38 (Sat, 24 Oct 1998 10:23:17 MDT)
:NNTP-Posting-Date: Sat, 24 Oct 1998 10:23:17 MDT
:Organization: Shaw Fiberlink Ltd. (Calgary)
:Xref: news3.best.com alt.gothic:468826 news.software.nntp:43195 alt.horror.werewolves:75944 rec.pets:43820
:
:NYC Pedophile Guy Polis likes young boys.
--
Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet
Communications
<dil...@best.net> (Please include original email in any response)
Matt Dillon
:> I think I see a way to deal with Supersedes: and related problems.
:>
:> What we do is require that the control message for any article being
:> canceled or any article containing a supersedes have an X-Trace: header.
:> The first element of the X-Trace: header must match one of the Path:
:> elements of the article being canceled or superseded.
:>
:> Presumably, the 'official' cancel generators either have a separate
:> propogation mechanism for their cancels, or have direct access to a
:> news transit box and can synthesize a matching X-Trace: header.
:>
:> We then pound all the NNTP software makers to either generate X-Trace:,
:> or to prevent a POST command from being able to synthesize its own
:> X-Trace:. A job that should be relatively easy.
:>
:> I like this a whole lot better then Cancel-Lock:, which is a really stupid
:> idea in my view.
:>
:> -Matt
Actually, lemme modify this: Instead of matching an element in the
Path: header, the first element of X-Trace: of the cancel/supersedes
article must match the first element of X-Trace: in the article being
canceled.
If X-Trace exists in one article but not the other, the supersedes/cancel
operation does not occur.
If X-Trace exists in NEITHER article, the supersedes/cancel operation
*DOES* occur.
If X-Trace exists in both but the first element does not match, the
supersedes/cancel operation does not occur.
If X-Trace exists in both and the first element does match, the
supersedes/cancel operation *DOES* occur.
-Matt
Clayton O'Neill
| I think I see a way to deal with Supersedes: and related problems.
|
| What we do is require that the control message for any article being
| canceled or any article containing a supersedes have an X-Trace: header.
| The first element of the X-Trace: header must match one of the Path:
| elements of the article being canceled or superseded.
|
| Presumably, the 'official' cancel generators either have a separate
| propogation mechanism for their cancels, or have direct access to a
| news transit box and can synthesize a matching X-Trace: header.
|
| We then pound all the NNTP software makers to either generate X-Trace:,
| or to prevent a POST command from being able to synthesize its own
| X-Trace:. A job that should be relatively easy.
|
| I like this a whole lot better then Cancel-Lock:, which is a really stupid
| idea in my view.
You need to have something that's a hell of a lot more secure than this.
X-Trace is not a standard and it's trivial to fake on most installations.
Althought I think the installed base to too large for it to happen easily, I
think the Cancel-Lock idea is a lot more secure.
Matt Dillon
:>:In article <70tcof$ogh$1...@flea.best.net>, Matt Dillon <dil...@best.net> wrote:
:>:> I think I see a way to deal with Supersedes: and related problems.
:>:>
:>:> What we do is require that the control message for any article being
:>:> canceled or any article containing a supersedes have an X-Trace: header.
:>:> The first element of the X-Trace: header must match one of the Path:
:>:> elements of the article being canceled or superseded.
:>:>
:>:> Presumably, the 'official' cancel generators either have a separate
:>:> propogation mechanism for their cancels, or have direct access to a
:>:> news transit box and can synthesize a matching X-Trace: header.
:>:>
:>:> We then pound all the NNTP software makers to either generate X-Trace:,
:>:> or to prevent a POST command from being able to synthesize its own
:>:> X-Trace:. A job that should be relatively easy.
:>:>
:>:> I like this a whole lot better then Cancel-Lock:, which is a really stupid
:>:> idea in my view.
:>:> -Matt
:>
:> Actually, lemme modify this: Instead of matching an element in the
:> Path: header, the first element of X-Trace: of the cancel/supersedes
:> article must match the first element of X-Trace: in the article being
:> canceled.
:>
:> If X-Trace exists in one article but not the other, the supersedes/cancel
:> operation does not occur.
:>
:> If X-Trace exists in NEITHER article, the supersedes/cancel operation
:> *DOES* occur.
:>
:> If X-Trace exists in both but the first element does not match, the
:> supersedes/cancel operation does not occur.
:>
:> If X-Trace exists in both and the first element does match, the
:> supersedes/cancel operation *DOES* occur.
:>
:> -Matt
*AND* the Newsgroups: line must match exactly, or the cancel/supersedes
operation does not occur.
I think if we do this, these attacks will be limited to nothing more
then a 'spam' attack or flood attack against a group and not cause
anywhere near the damage they currently cause.
Rahul Dhesi
> What we do is require that the control message for any article being
> canceled or any article containing a supersedes have an X-Trace: header.
> The first element of the X-Trace: header must match one of the Path:
> elements of the article being canceled or superseded.
How about finding the perfect long-term solution? I think we need a
scheme based on cryptographic techniques to verify cancels. I have seen
such schemes proposed in the past. As a software author you are in a
great position to institute and standardize such a scheme.
A supsersedes is just a cancel combined with a regular posting.
Each posting would include a cryptographic cookie. Cancels would be
accepted only from the original poster, verified with a cryptographic
signature.
News transit software could fill in authentiction information into all
locally-generated normal postings and cancel/supersedes postings. This
would allow cancels to be done only from the same site where something
was originally posted (which would solve 99% of the problem). So nntp
clients would not need to be modified.
Cancels would also be accepted from recognized spam cancellers.
I believe El Gamal public-key encryption is now patent-free. So it
would be a good scheme to use. We don't need all of the functionality
of PGP, just a small subset. I am not enough of a cryptographic expert
to do any of this, but perhaps somebody else who is reading this would
volunteer.
--
Rahul Dhesi <dh...@spams.r.us.com>
Jeremy
> I believe El Gamal public-key encryption is now patent-free. So it
> would be a good scheme to use. We don't need all of the functionality
> of PGP, just a small subset. I am not enough of a cryptographic expert
> to do any of this, but perhaps somebody else who is reading this would
> volunteer.
It'd be nice if whatever signature-only, exportable encryption thingy
that everyone wants to use (DSA or whatever it is) were available as
a Perl module. I don't have the C ability to write one...
--
Jeremy | jer...@exit109.com
Cleanfeed spam filter - http://www.exit109.com/~jeremy/news/cleanfeed.html
Matt Dillon
:Rahul Dhesi <c.c....@78.usenet.us.com> wrote:
:>In <70tcof$ogh$1...@flea.best.net> dil...@best.net (Matt Dillon) writes:
:>
:>> What we do is require that the control message for any article being
:>> canceled or any article containing a supersedes have an X-Trace: header.
:>> The first element of the X-Trace: header must match one of the Path:
:>> elements of the article being canceled or superseded.
Such a scheme would no more be a standard then X-Trace is. Since
X-Trace is already implemented on many news sites, it makes a hellofalot
more sense to turn X-Trace into an official header then to try to
introduce 'yet another header'.
If I implement a scheme based on X-Trace, it has a much greater chance
of succeeding then a scheme based on some new cryptographic header.
Even though there will still be NNTP sites that do not filter
user-supplied X-Trace headers, allowing an attacker to match his
posting against the original he is trying to supersede, at least we
will have a large number of NNTP sites that *already* filter out
X-Trace headers, making it impossible for a user with only NNTP
access to fake a cancel or supercedes.
If we implement an official trace header, we can require that X-Trace:
still be filtered out in the official standard to provide an upgrade
path from X-header to standard.
Furthermore, a cryptographic scheme disallows administrative cancels or
supersedes. I want to keep administrative cancels or supersedes because
it is much easier to keep news administrators in line then it is to
keep users in line.
-Matt
:>--
:>Rahul Dhesi <dh...@spams.r.us.com>
Matt Dillon
:>Matt Dillon <dil...@best.net> wrote:
:>> What we do is require that the control message for any article being
:>> canceled or any article containing a supersedes have an X-Trace: header.
:>> The first element of the X-Trace: header must match one of the Path:
:>> elements of the article being canceled or superseded.
:>This is a bad joke rather than an authentication mechanism.
:>Just as INNs "VERIFY_CANCEL" option.
:>
:>> I like this a whole lot better then Cancel-Lock:, which is a
:>> really stupid idea in my view.
:>
:>(Apart from the fact that in order to be effective, it has to be
:>widely deployed, which is true for your scheme too?)
:>
:>olaf
What happens when a spammer cancel-locks his postings ?
You see the problem now? We still need to allow administrative
cancels. Having an authentication scheme sounds all find and
dandy, but just doesn't work when the vast majority of cancels
come from what most administrators would consider *valid* third
parties.
Cancel-lock provides a mechanism by which the original poster or
nntp server can cancel a posting, and nobody else. This is totally
useless.
In order to allow third-party administrative cancels, you
have to differentiate between a *USER* and a *NEWS ADMINISTRATOR*.
The only way to differentiate the two is to give the
news admin the ability to specify a header that the user
is not allowed to generate himself. Now, I am not bent on
X-Trace being that header, but given the choice between
making X-Trace official and introducing yet another new
header, I would personally rather stick with X-Trace.
And while it is true that X-Trace has the same theoretical
problem that a cancel lock header has, at least X-Trace is
already in widespread use, whereas cancel lock isn't.
And while it is true that one cannot guarentee the good graces
of every news admin, there are a whole lot fewer of them then
there are users and a definitive mechanism through which pressure
can be brought on an out-of-line news admin. The USENET is still
about trust, at least on some level.
-Matt
Rahul Dhesi
>It'd be nice if whatever signature-only, exportable encryption thingy
>that everyone wants to use (DSA or whatever it is) were available as
>a Perl module. I don't have the C ability to write one...
El Gamal is available as a perl module from http://www.systemics.com/ .
However it uses C code which I could not compile without errors with gcc
under SunOS.
Short, simple perl-only code would be great, if somebody would
contribute it. It would be terrific if somebody outside the USA would
make it available for worldwide use.
--
Rahul Dhesi <dh...@spams.r.us.com>
Matt Dillon
:Russ Allbery <r...@stanford.edu> wrote:
:>Matt Dillon <dil...@best.net> writes:
:>
:>> What happens when a spammer cancel-locks his postings ?
:>
:>The same thing as when a spammer has an X-Trace header under your system.
:>You have to work around it if you want to use cancels to eliminate spam.
huh? I have no idea what you are talking about here. Of *course*
a spammer with access to a system that doesn't support X-Trace will still
be able to use the supersedes attack. I said as much in my last posting
(which you apparently haven't bothered to read). That isn't the point
at all.
:>
:>And they are going to need *stronger* authentication than regular article
:>cancels, should be batched, and ideally should have a clearly delegated
:>chain of authority.
:>
:>This has been discussed ad nauseum on usefor. All of the arguments you're
:..
:>to handle the harder problems like spam cancellation. You can't do
:>full-blown certificate systems for all Usenet traffic in the near term
:>because your CA can't scale. We have no infrastructure. You can't use
We have an infrastructure, it's being used right now to authenticate
newgroup, rmgroup, and checkgroup commands. The only problem with it is
that PGP is a relatively expensive operation, especially when one
must fork/exec the authentication program for each message. But beyond
the overhead, the group-hierarchical infrastructure itself is quite sound.
Cancel batching is a neat idea, and it could be done a little, but batching
imposes latencies which inherently limits the size of the batch. It might
be enough to solve a PGP-like delay (one batch every 5 minutes wouldn't be
too bad in aggregate), but it does not fit in the existing
group-hierarchical infrastructure very well.
Cancel-lock doesn't fit in the existing (and I think necessary) group-
hiearchical administrative infrastructure at all. How does the designated
moderator or spam-control engine for a hierarchy impose administrative
control with cancel-lock? It can't. That kills it.
:>> the choice between making X-Trace official and introducing yet
:>> another new header, I would personally rather stick with X-Trace.
:>
:>Your system breaks in a network that contains non-upgraded servers.
:>I'm afraid that kills it dead, since the one thing we'll never manage to
:>do is upgrade all of Usenet. Any solution to this problem *has* to have
:>the effect of localizing the remaining effects of the problem at the sites
:>that have not yet upgraded.
Well doh. You think cancel-lock does? Cancel-lock is *WORSE*.
You haven't addressed a single point that I've made, and you obviously
haven't bothered to read my postings very carefully. Try rereading them
and addressing the points. I will only repeat: Any system that
takes away third party administrative control is doomed from the get-go.
It just won't work. Cancel-Lock is no-better then double-posting an
article using a cancel- message-id dummy control in the duplicate. It
fixes nothing, and takes away mechanisms that administrators rely on
right now. Nobody in their right mind would implement it.
It would not be difficult to extend the existing Control: message
mechanisms to cover the more recent problems that have cropped up on
the USENET (recent == last 5 years or so). Nobody should be talking
about adding silly new headers. I don't even think cancels need to be
special cased, public key encryption isn't *that* slow, just a slightly
too bulky to be used for high-volume operations. All we need is
a somewhat less bulky public-key standard which can be distributed through
existing mechanisms such as the ISC and can be easily encapsulated in a
library.
I could, right now, take 'pgp' and crunch it into a library that I simply
link with Diablo and it would be able to handle the cancel load just fine.
I don't particularly *like* pgp, which is why I haven't done it, but
the key-ring concept is quite sound and if one could slim the mechanism
down a bit it would work just fine with per-message cancels.
-Matt
:>--
:>Russ Allbery (r...@stanford.edu) <URL:http://www.eyrie.org/~eagle/>
Department of Usenet Abuse
> Cancel batching is a neat idea,
Cancel batching is a horrible idea. I'm used to seeing Cosmo cancels
arriving at the same time as the spam it nabs, within a second or two,
by watching my news logfile or history file.
The measurements I've made show that on a limited feed, I'm spending
nearly half the time filtering the incoming feed, far more time than it
takes to write the articles to disk. I haven't further analyzed to see
why it's so fscking slow, but it's intolerable and I'm on the verge of
disabling filtering entirely and relying on Cosmo.
As a contrast, I see that the time needed to unlink the articles being
cancelled is on the order of a few seconds, and the reason is clear --
if cancels are arriving at the same time as the articles themselves,
they never even get written to the disk except for a small window around
the syncs every 30 seconds of our unix type of filesystem.
If the cancels are delayed by batching, then the articles have already
been flushed to the disk and I'm sure the operation needed to effect a
cancel will be a lot more expensive. Nonetheless, I bet it's far more
expensive to filter on everything rather than unlink a quarter of what
gets written sometime after-the-fact, given what I have in front of me.
Now, if people aren't running in a way that Cosmo's cancels are arriving
in realtime, they probably won't see the performance boost that we'd see
by relying on cancels issued by an engine with far more horsepower and a
much larger database than I can devote to filtering.
And as the need for increasingly more complex filtering becomes greater,
more and more sites will probably see the same thing that I do, where a
few simple rules, plus aggressive filtering on locally-originated postings
is the way to go, supplemented by reliance on a real-time-distributed feed
of (presumably) simply-authenticated cancels, will enable them to spend
more time writing the articles (but not really writing them) and unlinking
them before they have had time to hit the spool proper.
> Cancel-lock doesn't fit in the existing (and I think necessary) group-
> hiearchical administrative infrastructure at all. How does the designated
> moderator or spam-control engine for a hierarchy impose administrative
> control with cancel-lock? It can't. That kills it.
That's where your external authenticated feed must come into play, and
is one of the reasons why I haven't been able to be too fascist about
restricting user-issued cancels by our customers to keep the local
hierarchy clean. Here, as the cancels are not happening in real time,
the unwanted articles have long since been flushed to the disk. The same
may not be true of other hierarchies running 'bots, but the number of
such cancels would be far outweighed by those issued in realtime by Cosmo.
barry «no longer considers Cosmo Roadkill the epitome of evil» bouwsma
Clayton O'Neill
|Unless this header contains cryptographically authenticated stuff
|(which Cancel-Lock does), this proposal is doomed to fail. Each and
|every header is trivial to forge, no matter how many checks you put
|into the POST routine. IMHO, it would be better to refrain from
|anything but sanity checks at that point, because you can circumvent
|stuff like the Sender and X-Trace controls anyway. Putting trust in
|headers that can be added by a spammer in any way only gives a false
|sense of security. Do you actually believe the Sender header? If not,
|why do you think you could believe an X-Trace header? Okay, I do
|believe an X-Trace header _if_ I know the sending site is running a
|recent INN and I can verify from the Path header that the sending site
|is in fact the sending site...
I trust our X-Trace headers since we've recently moved to encrypting them. This
preserves the privacy of our customers and also guarantees that complaints
we get are actually our users and not forgeries.
Matt Dillon
:>You're arguing against cancel locks on the grounds that they make spam
:>cancellation impossible, and I'm pointing out that straight X-Trace does
:>the same thing. You're proposing an *alternative* system (namely an
:>injection host that doesn't add X-Trace). I'm doing the same thing
:>(namely an authentication system for cancels that overrides cancel locks).
:>I think mine is better designed and more secure than yours is.
Uh, no, X-Trace doesn't do the same. You missed my point about user
and administrative level access to the news system.
A news admin can inject a cancel with the correct X-Trace (or whatever
is eventually decided on) header. You *haven't* read my posting
carefully. Read that part again, I only repeated in three times in my
last few postings.
:>> We have an infrastructure, it's being used right now to authenticate
:>> newgroup, rmgroup, and checkgroup commands.
:>
:>But I was specifically talking about cancels, for which we do not have an
:>infrastructure since it would require keys for every poster. I think that
:>you agree with me on this point, given the X-Trace proposal, so I'm not
:>sure what you're arguing with.
If you haven't noticed, cancels can already run under the existing
authentication infrastructure.
So I will repeat: All that needs to be done is to fix the PGP part
of it, and the existing authentication infrastructure can be used to
process signed cancels. There is no need for a new infrastructure.
:>> But beyond the overhead, the group-hierarchical infrastructure
:>> itself is quite sound.
:>
:>*For group infrastructure*. It's unclear if it will scale even to the
:>number of current active moderators; it's pretty clear that it's not going
:>to cleanly scale to every poster on Usenet.
It's very clear to me... each subhierarchy is controlled by entities that
have as vested interest in the subhierarchy. You also have a number of
global entities that have vested interests in the entire hierarchy.
The existing infrastructure ALREADY HANDLES BOTH CASES. Take a look at
the wildcarding in a modern control.ctl and you will see it.
:>That's the argument against using a CA system to authenticate all cancels,
:>including individual cancels. That isn't something you were proposing; it
:>was an aside.
:>
:>The current infrastructure almost certainly is good enough to scale to the
:>number of active large-scale spam cancellers.
The current infrastructure, with only minor adjustments to the PGP
authentication currently being employed, is good enough to scale to
wherever the USENET is going for the next ten years, trivially, and
probably way beyond that. The overhead required to manage a few thousand
public keys is virtually zip.
Tell me why you think this isn't so and maybe I'll listen, but you are
trying to justify not using an infrastructure that scales perfectly to
the problem and I just don't believe it.
:>> Cancel-lock doesn't fit in the existing (and I think necessary)
:>> group-hiearchical administrative infrastructure at all.
:>
:>I think you're very confused about what cancel locks are and aren't. A
:>cancel lock is nothing more or less than a way of determining whether
:>article A was posted by the same entity as article B.
All cancel lock is is a personal authentication mechanism. It works
fine if you want to verify that an individual canceling or superseding
an article is the same individual that posted it, but is completely
useless beyond that. Using X-Trace would not give the same level of
authentication, but you are still missing the fact that you have to
poke so many holes into cancel-lock to make third party administrative
cancels work anyway that cancel-lock itself would be no better. So
why use it at all?
:>That's important. Let me repeat it. *Cancel locks do not tell you what
:>cancels should not work, only what cancels should work.* If the locks
:>don't match, then you're reduced to precisely the same situation that we
:>have now.
It's a lot of added and completely unnecessary infrastructure which will
result in the news systems software having to implement multiple
mechanisms to handle a single operational parameter - cancels. There is
no way I would ever implement it without first seeing a general
third-party administrative solution for cancels that uses the existing
(and perfectly workable) Control: infrastructure.
:>> How does the designated moderator or spam-control engine for a
:>> hierarchy impose administrative control with cancel-lock? It can't.
:>
:>Of course they can. They issue a cancel just like they do now. You just
:>can't use cancel locks to verify it; you have to use something else.
Which is the problem. Why bother with cancel locks when it doesn't solve
the larger issue?
The current PGP mechanisms for the control hierarchy work extremely
well and with only a small amount of work would work wonderfully for
cancels as well. I would consider cancel locks only after the larger
issue of third party administrative control was solved for cancels.
:>> Well doh. You think cancel-lock does? Cancel-lock is *WORSE*.
:>
:>Only because you're very confused.
Your argument is basically to throw piecemeal solutions into the pot.
The only result of doing things like that will be a mass of messy
code implementing dozens of piecemeal solutions. That is not where
I want to go.
:>> distributed through existing mechanisms such as the ISC and can be
:>> easily encapsulated in a library.
:>
:>And a CA that can issue keys for everyone on Usenet. I think that's a
:>great problem to try to solve, but I don't expect to see it solved in the
:>next ten years.
:>
:>--
:>Russ Allbery (r...@stanford.edu) <URL:http://www.eyrie.org/~eagle/>
An official CA doesn't have to get involved at all. Anyone can issue
their own public keys. The news admin can decide to use it or not, just as
the current infrastructure works. News admins will tend to get their
public keys from known entities such as the ISC or UUNET. These
organizations 'become' the CA, but are by no means the only sources for
keys. My control file and PGP key rings contains a mix of uunet/isc and
third party public keys to validate both U.S. and foreign hierarchies.
It works wonderfully, it's just a tad inefficient. But nothing that
couldn't be fixed relatively easily.
-Matt
Matt Dillon
:>Matt Dillon <dil...@best.net> wrote:
:>
:> own Cancel-Lock in addition to the spammer's one. The spammer is
:> not able to avoid that. The news admin of that site can do an
:> authenticated cancel on it.
Which is completely useless. When was the last time you were able to
get a news admin to cancel spams issued from his site? There are
thousands of sites on the USENET.
It's third party administrative control or nothing. That is: global
cancel entities and moderators who want to run their own filter software
for the groups under their control.
Cancel-Lock addresses neither issue.
:>(b) Bulk cancellation from despammer 'bots are done authenticated with
:> NoCeM, as they are for some years now.
:>
:>> In order to allow third-party administrative cancels, you
:>> have to differentiate between a *USER* and a *NEWS ADMINISTRATOR*.
:>
:>For a user or his own administrator, you have to authenticate against
:>himself; for a third party you have to authenticate against its
:>identity. The former is done by Cancel-Lock, the latter by PGP. The
:>latter requires a public key infrastructure, the former not.
99% of all cancels are from the former. No, I take that back...
99.99% of all cancels are from the former. Solve the former
problem first. Cancel-Lock doesn't.
:>> news admin the ability to specify a header that the user
:>> is not allowed to generate himself. Now, I am not bent on
:>
:>Unless this header contains cryptographically authenticated stuff
:>(which Cancel-Lock does), this proposal is doomed to fail. Each and
:>every header is trivial to forge, no matter how many checks you put
:>into the POST routine. IMHO, it would be better to refrain from
Huh? Uh, no, that isn't true really. a person with administrative
control would be able to forge everything except leading elements of
the Path: header. No *user* with access to an NNTP server supporting
X-Trace can issue his own. Certainly a user with access to an NNTP
server not supporting X-Trace could issue his own. I've repeated that
over and over again... Cancel-Lock isn't any better, really, because
even fewer people will deploy it (whereas there is a better chance for
X-Trace being deployed on a mass scale). It may prevent someone from
canceling *your* posting, but it won't even come close to solving the
larger problem of bozos attacking the USENET.
:>> already in widespread use, whereas cancel lock isn't.
:>
:>That argument is invalid since we want to implement authentication.
:>Authentication is a feature that is not present at all in the current
:>Usenet. We _have_ to add something.
Add a viable key-ring-based authentication scheme for control messages
and the problem is effectively solved.
:>> can be brought on an out-of-line news admin. The USENET is still
:>> about trust, at least on some level.
:>
:>Experience has shown that when we leave a certain scale upwards, trust
:>ceases to work, but we can fully replace trust by authentication.
:>
:>olaf
Trust only ceases to work with the userbase because they do not have
a vested interest in keeping the USENET sane. Trust definitely still
works with the administrative infrastructure, and it's trivial to alias
out those few hosts, such as alt.net, which manage to stay connected
to the infrastructure but don't give a damn about the damage they cause.
-Matt
:>--
:>___ Olaf...@inka.de or @{stud,informatik}.uni-karlsruhe.de ____
Jean-Francois Stenuit
>
> Jean-Francois Stenuit <lon...@skynet.be> writes:
>
> > As the same problems exists for all kind of approach (both cancel-lock
> > and X-trace), namely that these headers can be forged, we must be able
> > to set a "trusted" flag on our peers. And that goes for many other
> > problems.
>
> Actually, no, that problem doesn't affect cancel locks, as cancel locks
> cannot be forged easily enough to be effectively exploited. That's the
> whole point of using a cryptographic solution.
Ooops, yes, you're right.
The only remaining problem now is the client side. Most user don't
even know what a digital signature is. Do you think that poster
systems (leaf nodes of the news propagation web) can implement this
signature ?
When the key is generated by the first usenet node, it should be based
on both a secret site key and the authenticated id of the user, of
course.
That way, the Cancel-lock can be implemented without the clients
knowing anything about it. If nobody is against this kind of
implementation, I think I will implement it next week.
--
Opinions expressed above are mine, they have not to be taken as a
skynet official position.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
/Jean-Francois "Jef" Stenuit | BELGACOM-Skynet NV/SA | Solaris 2.x, \
\Network operations manager | 124, Rue Col. Bourg | Linux, NT, /
/Phone (32)(2) 706-1311 | B-1140 Brussels | Cisco \
\Fax (32)(2) 726-9823 | Belgium | expert ... /
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Department of Usenet Abuse
> A news admin can inject a cancel with the correct X-Trace (or whatever
> is eventually decided on) header.
And so can a lot of other people, in particular, the vandals who are
able to cancel posts without authentication, given that this header
is only forced on in recent software. Further, those sites confgured
to send outgoing news via «POST» (and I know how we all love them) will
either have to strip this header before submitting it to an INN-like
server lest the post be rejected outright, or have it quietly overwritten
by Typhoon-like servers. We're still plagued by lots of sites where no
NNTP-Hosting-Post header is added, or where it changes during transfer.
> The current infrastructure, with only minor adjustments to the PGP
> authentication currently being employed, is good enough to scale to
> wherever the USENET is going for the next ten years, trivially, and
I know of more than a few newsadmins who saw their machines with loads in
the four-digit range during the recent newgroup flood who would likely
disagree with you. And the 30 000-odd newgroup messages that got out over
those few hours is roughly a tenth of the number of individual cancels
issued for BI spam per day around a year ago, before the numbers started
dropping as a result of admin response to the cancel moratoria.
And in spite of PGP authentication having long been available, most of
the sites I looked at had gone ahead and created the news.pedophile.*
hierarchy. It's not like admins actually pay attention to their servers
or anything...
> All cancel lock is is a personal authentication mechanism. It works
> fine if you want to verify that an individual canceling or superseding
> an article is the same individual that posted it, but is completely
> useless beyond that. [...] So
> why use it at all?
I thought the subject of this thread was Cat Bathing, or something about
the ability of random vandals to cancel messages with no problems on sites
which process cancels. I'm not sure what brought it up now, as I've not
seen any evidence of this thread or any others people are complaining
about, but then, I recompiled INN in anticipation of this some time back
as well as added some censorous configuration. Oh well.
> An official CA doesn't have to get involved at all. Anyone can issue
> their own public keys. The news admin can decide to use it or not, just as
> the current infrastructure works.
Don't you mean, how it doesn't work? Look at all the mysterious hierarchies
floating around out there, there isn't even a comprehensive one-stop-shopping
solution to cover all of those for admins setting up the hierarchies, much
less managing the hierarchies, each with their own rules.
Matt Dillon
to the problem.
How about this. I could implement this in about three days for Diablo
using the RSAREF library, inclusive of all the key-ring management
functions.
README.RSA
Diablo Experimental Feature
This feature is designed to implement a new RSA public-key authenticated
control message format. It works in a manner similar to PGP but is
somewhat easier to use. The existing control infrastructure is used.
The new authentication format may also be used for authenticating cancels
and supersedes.
Usage:
* Used by individuals to sign articles with their public key
* Used by individuals to add their own administrative control
keys (such as a key to allow the individual to securely cancel
his own article).
* Used by news systems to add their own adminstrative control
keys.
* Used by moderators to add their own administrative control or
authentication keys, allowing articles posted to moderated groups
to be authenticated with the moderator's key (that is included
in the newgroup message for the group or otherwise propogated).
* Used by third parties to authenticate control messages such as
cancels, newgroup, rmgroup, and so forth, with their public
keys distributed via a separate mechanism.
* Used by anyone to propogate a public key.
* Allows key associations, where the distribution of a public key may
be authenticated with a pre-existing key.
For example, a moderator could hand out keys to helpers or even to
various spam-canceling bodies that he wishes to give administrative
control (or just cancel access) to.
Field definitions:
identifier:
Identify the public or private key. May contain
alpha-numerics, dashes, colon, slash, question-mark,
period, at-sign, plus-sign, and tilde.
Typically in the form of a URL, user@fqdn, or group-name.
format:
Encryption format used, typically RSA128 for an article
and RSA1024 for a control message.
headerlist:
a list of comma delimited headers. Only headers with
alpha-numerics and dashes may be specified here.
signature:
The signature computed from the specified headers and (if
specified) body, matching the MD5 of the article after
encrypting with the public key. Only the specified headers
and/or body is involved in the encryption/md5 check.
public-key:
A public key in the specified format, in ascii (typically
in hex ascii).
private-key:
A private key in the specified format, in ascii (typically
in hex ascii).
access-list:
Administrative access list. The list is further restricted
by the context of the message and the access the related parent
key was given. i.e. when you have a relationship between
a parent key and sub-key, the sub-key cannot grant access
beyond what the parent key granted it.
md5:
An md5 checksum of the current header, non-inclusive
of the '5=md5' or terminating LF, but inclusive of
the space preceeding the 5= key-value pair. This
key-value pair must be the last key-value pair on the
line.
HEADERS
X-DRsaSig: I=identifier F=format H=headerlist S=signature 5=md5
Used to sign a normal posting or control message. There are no guard
characters. The specified headers and body (if included) must be
8-bit clean. This also means that the body must terminate with an LF
prior to escaping. The 8-bit clean article must be '.' and LF->CRLF
escaped by the NNTP protocol and de-escaped (remove '.' and CRLF ->LF)
on the remote side. An article containing CR's in de-escaped form is
allowed but must be properly escaped/deescaped, i.e. CRLF->CRCRLF
and CRCRLF->CRLF.
Multiple X-DRsaSig headers may be specified, allowing a user to give
access to second parties, allowing a news system to append its own
X-DRsaSig header for additional administrative control, and allowing
third party mechanisms to sign control messsages with their own
(possibly separately distributed) keys. Administrative control is
a propogation mechanism so, for example, an intermediate hop may
add its own signature to the header. This capability, however, is
not recommended for general purpose use.
The signature is based on the unescaped 8-bit clean form of the
article.
The news system tests the signature on an as-needed basis, typically
from the news system's public key ring file or DBM'd key ring.
X-DRsaKey: I=identifier F=format P=public-key A=access-list 5=md5
Optional in messages, allows the user to distribute his public-key
via the news system. These keys are typically picked up by news
admins manually but a self-authentication URL form is allowed to
give administrators and users the ability to pick up publically
distributed keys either manually, semi-automatically, or automatically
(and, as a consequence, with varying levels of security associated with
the key).
It is also possible to sign a public key with a separately
authenticated private key (have both X-DRsaKey and X-DRsaSig, where
XDRsaSig signs all XDRsaKey's) and to have the news system
automatically pick up the new key if it already trusts the
authentication key. The relationship is recorded in the keyfile and
may later be destroyed by the same mechanism by specifying
a format in X-DRsaKey of '@destroy' and a wildcard for the identifier.
In this case, any relationships based on the private key and matching
the wildcard are recursively destroyed (removed) from the key ring.
X-DRsaAway: I=identifier F=format U=private-key 5=
May be used in cancels, supersedes, or any article which creates a
side effect on some other article. Allows a user or administrator
to sign postings with a random key. If the user then wishes to
override (cancel or supersede) the posting, hey may provide the
private key in this header. The private key is only used to
authenticate the original posting. The original posting need not
contain the X-DRsaKey header to be overriden in this manner.
The distribution of any private key will, if authenticated against
a public key for that identifier in the news system's key-ring file,
destroy the public key in the news system's key-ring file as well
as any recursive relationships based on that key.
SPECIFIC FORMATS USED FOR USENET NEWS
Matt Dillon
:>> of it, and the existing authentication infrastructure can be used to
:>> process signed cancels. There is no need for a new infrastructure.
:>
Nonsense. Why ?
Matt Dillon
:Jean-Francois Stenuit <j...@skynet.i8spam.be> wrote:
:>Matt Dillon wrote:
:>>
:>> How about this. I could implement this in about three days for Diablo
:>> using the RSAREF library, inclusive of all the key-ring management
:>> functions.
:>Woops ... is RSAREF free for export outside US ? I'd like to experiment
:>the feature as well ;-)
:>
:>--
:>Jean-Francois "Jef" Stenuit
:>Network Operations Manager
:>Belgacom Skynet
Probably not, but I was under the impression that someone outside
wrote a compatible API, which is all that really matters. Anyone know?
rsaref has a really simple API. What does SSH-1.2.x use?
Since we are not using it to encrypt anything, just authenticate, it might
be legal. I dunno. I wouldn't be distributing rsaref itself, I'd just
have the hooks in Diablo to use it.
-Matt
Andreas Barth
> What happens when a spammer cancel-locks his postings ?
Andi
--
Andreas Barth <a...@muenchen.pro-bahn.org> PGP-Key auf Anforderung
======PGP-Fingerabdruck DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C======
Aber die Halbwertszeit der Planungen der Stadtwerke werden wohl
auch immer kuerzer ... Lucas Neubauer
Andreas Barth
> It's third party administrative control or nothing. That is: global
> cancel entities and moderators who want to run their own filter software
> for the groups under their control.
I missed your argument against nocem.
:>>> In order to allow third-party administrative cancels, you
:>>> have to differentiate between a *USER* and a *NEWS ADMINISTRATOR*.
> 99% of all cancels are from the former. No, I take that back...
> 99.99% of all cancels are from the former. Solve the former
> problem first. Cancel-Lock doesn't.
The problem is solved. Use nocem.
> X-Trace can issue his own. Certainly a user with access to an NNTP
> server not supporting X-Trace could issue his own. I've repeated that
And there are enough open servers without x-trace.
Matt Dillon
:brian moore <b...@news.cmc.net> wrote:
:>On 25 Oct 1998 13:15:08 -0800,
:> Matt Dillon <dil...@best.net> wrote:
:>> Ok, Lets put this on a more positive note and discuss a general solution
:>> to the problem.
:>>
:>> How about this. I could implement this in about three days for Diablo
:>> using the RSAREF library, inclusive of all the key-ring management
:>> functions.
:>Use non-patented technology. (Hint: you can't use RSA on a server
:>without paying a licensing fee.)
:>
:>Diffie-Hellman's patent has expired.
Have you read the licencing terms for rsaref recently ? If the software
isn't commercial (i.e. sold for money), you can use it.
-Matt
:>--
:>Brian Moore | "The Zen nature of a spammer resembles
:> Sysadmin, C/Perl Hacker | a cockroach, except that the cockroach
Matt Dillon
Works under the existing infrastructure.
README.PKE
Diablo Experimental Feature
This feature is designed to implement a new PKE authenticated
control message format. It works in a manner similar to PGP but is
somewhat easier to use. The existing control infrastructure is used.
The new authentication format may also be used for authenticating
control messages, including cancels and supersedes, and may be used to
sign normal articles (as a way of implementing a cancel lock).
Essentially, what we want is a delegateable (recursive) public key
infrastructure which redursively assigns and passes access rights
and group restrictions (group wildcards). Every control article
in the system is authenticated by this mechanism, including
indirect control operations such as, say, Supersedes:. If you trust
the right entities, the system is auto-maintained.
Usage:
* Used by individuals to sign articles with their public key.
(note: the news server does not necessarily process such keys)
* Used by individuals to add their own administrative control
keys (such as a key to allow the individual to securely cancel
his own article).
(note: the news server does not necessarily process such keys)
* Used by news systems to add their own adminstrative control
keys.
* Used by moderators to add their own administrative control or
authentication keys, allowing articles posted to moderated groups
to be authenticated with the moderator's key (that is included
in the newgroup message for the group or otherwise propogated).
* Used by third parties to authenticate control messages such as
cancels, newgroup, rmgroup, and so forth, with their public
keys distributed via a separate mechanism.
* Used by anyone to propogate a public key.
* Allows key 'recursion' rights, where the distribution of a public
key may be authenticated (delegated) with a pre-existing key.
For example, a moderator could hand out keys to helpers or even to
various spam-canceling bodies that he wishes to give administrative
control (or just cancel access) to.
Field definitions:
identifier:
Identify the public or private key. May contain
alpha-numerics, dashes, colon, slash, question-mark,
period, at-sign, plus-sign, and tilde.
Typically in the form of a URL, user@fqdn, or group-name.
format:
Encryption format used, i.e. PKE1024 or something like
that.
headerlist:
a list of comma delimited headers. Only headers with
alpha-numerics and dashes may be specified here.
signature:
The signature of the article is computed from selected
headers, the current header (minus the signature itself),
and possibly the message-body. The data is MD5'd and run
through the private key.
The signature is verified by separately MD5'ing the data
and running the signature through the public key. If a
match occurs, the signature is considered validated.
public-key:
A public key in the specified format, in ascii (typically
in hex ascii).
private-key:
A private key in the specified format, in ascii (typically
in hex ascii).
access-list:
Administrative access list. The list is further restricted
by the context of the message and the access the related parent
key was given. i.e. when you have a relationship between
a parent key and sub-key, the sub-key cannot grant access
beyond what the parent key granted it.
HEADERS
X-DPkeSig: I=identifier F=format H=headerlist S=signature
Used to sign a normal posting or control message. There are no guard
characters. The specified headers and body (if included) must be
8-bit clean. This also means that the article body must terminate
with an LF prior to escaping. The 8-bit clean article must be '.'
and LF->CRLF escaped by the NNTP protocol and de-escaped (remove
'.' and CRLF ->LF) on the remote side. An article containing CR's in
de-escaped form is allowed but must be properly escaped/deescaped,
i.e. CRLF->CRCRLF and CRCRLF->CRLF.
Multiple X-DPkeSig headers may be specified, allowing a user to give
access to second parties, allowing a news system to append its own
X-DPkeSig header for additional administrative control, and allowing
third party mechanisms to sign control messsages with their own
(possibly separately distributed) keys. Administrative control is
a propogation mechanism so, for example, an intermediate hop may
add its own signature to the header. This capability, however, is
not recommended for general purpose use.
The signature is based on the unescaped 8-bit clean form of the
article.
The news system tests the signature on an as-needed basis, typically
from the news system's public key ring file or DBM'd key ring.
X-DPkeKey: I=identifier F=format P=public-key A=access-list G=group-list
Generally occurs only in 'delegate' control message. May occur
in any message but may not necessarily be processed by the server.
Allows the news admin to distribute his public-key via
the news system. Allows a user to distribute his public-key via
the news system. Allows a trusted entity to propogate or destroy
a delegation to another key (if the X-DPkeSig header also exists
and signs all X-DPkeKey headers).
In the case of a delegated key, the hierarchical relationship is
recorded in the keyfile and may later be (recursively) destroyed
by the same mechanism by specifying a format in X-DPkeKey of
'#destroy'.
A list of access rights and a group wildcard restriction is passed
with the delegation. While you can specify any set of access rights
and '*' for the group, the actual access rights and group restrictions
will be limited to access rights and group wildcards allowed by the
delegating authority. So, for example, the delegating authority for
'comp.*' might delegate cancel authority for 'comp.binaries.*' to
a third party spam canceler.
X-DPkeAway: I=identifier F=format S=signature
May be used in cancels, supersedes, or any article which creates a
side effect on some other article. Allows a user or administrator
to sign postings with a random key. If the user then wishes to
override (cancel or supersede) the posting, he can sign the header
with the private key associated with the identifier.
If the key being given away exists in the key ring, it is marked
obsolete and will no longer be accepted by the system after the
operation completes. If the key does not exist in the key ring
it is expected to exist as a X-DPkeKey header in the posting
being canceled, superseded, or otherwise effected by this article.
DIABLO OPERATIONS
To enable diablo-based key rings within diablo, diablo must be compiled
with a working rsaref.2 (XXX) library and the key ring must be initialized.
dcontrol.ctl must be setup to require the use of the keys in a manner
similar to the way PGP is used. Each key in the keyring is broken
up into several parameters:
* The label, naming the key
* The public portion of the key
* The private portion of the key (only exists for keys which you
know the private side for. May be password protected).
* Group wildcard restrictions for the key, typically '*' (i.e. overall
group restriction is taken from dcontrol.ctl).
* Access rights associated with the key (made up of keywords)
Access rights are given below. These are keyword-based, and therefore
extensible.
* rmgroup allow auth source to issue rmgroup
* newgroup allow auth source to issue newgroup
* checkgroups allow auth source to issue checkgroups
* moderator
* supersedes allow auth source to issue supersedes
* cancel allow auth source to issue cancels
* recursion allow delegation
* subrecursion allow delegated key to also delegate
The KeyRing is stored in a Diablo DKP database (i.e. a human readable,
machine editable key-token-value database).
The KeyRing system is hierarchical. At the top level are the keys that
you yourself have created in the system. You give your keys a set of base
access rights. These keys are typically never used to sign anything.
Instead, you associate trusted key sources with your keys. For example,
if the ISC were to distribute a set of keys, you could ftp them and then
associate them with one of your master keys.
The hierarchy is used specifically to transfer access rights. You specify
a base set of access rights in your master keys. Any keys created under
your master keys are also created with a set of access rights, but each
level in the hierarchy can only *restrict* access rights, so if you do
not give, say, the cancel access right in a master key, the other keys
you associate with it will not have the cancel access right even if they
specify that they want it.
Matt Dillon
to have to use PGP.
-Matt
Jean-Francois Stenuit
> > canceled or any article containing a supersedes have an X-Trace: header.
> > The first element of the X-Trace: header must match one of the Path:
> > elements of the article being canceled or superseded.
>
> This is a bad joke rather than an authentication mechanism.
> Just as INNs "VERIFY_CANCEL" option.
Anyway, this cannot work, as the Path: header can be easily forged (in
fact, Cancel/Supersedes spammers already copy parth of the "Path:"
header).
> > I like this a whole lot better then Cancel-Lock:, which is a
> > really stupid idea in my view.
>
> And where exactly lies the problem with Cancel-Lock?
> (Apart from the fact that in order to be effective, it has to be
> widely deployed, which is true for your scheme too?)
Well, I prefer the cancel-lock approach, but we must take the side
effects into account.
Let's take the cancel-lock approach only for user cancels.
Administrative/batch cancels should take another way round. Using a
simple signature (SHA ?) for user cancels and a more complex scheme (PGP
?) for the administrative cancels.
As the same problems exists for all kind of approach (both cancel-lock
and X-trace), namely that these headers can be forged, we must be able
to set a "trusted" flag on our peers. And that goes for many other
problems.
I.e. I will flag a peer that ensure the "X-Trace" and "Cancel-Lock"
policy as trusted.
If I get a Supersedes/Cancel message from a trusted peer, I can go on
and proceed with the checks against the cancel-lock or the X-trace
headers. If I get this kind of message to a non-trusted peer, I will
discard the message. This won't affect administrative cancels, as those
messages will take another way.
IMHO, the first step is to set up this "trusted peers" scheme, as
without it none of the header-based protection can work.
--
Jean-Francois "Jef" Stenuit
Network Manager
Belgacom Skynet
Jean-Francois Stenuit
>
> How about this. I could implement this in about three days for Diablo
> using the RSAREF library, inclusive of all the key-ring management
> functions.
Woops ... is RSAREF free for export outside US ? I'd like to experiment
the feature as well ;-)
--
Jean-Francois "Jef" Stenuit
Network Operations Manager
Belgacom Skynet
Jean-Francois Stenuit
>
> On 24 Oct 1998, Matt Dillon wrote:
>
> > Cancel batching is a neat idea,
>
> Cancel batching is a horrible idea. I'm used to seeing Cosmo cancels
> arriving at the same time as the spam it nabs, within a second or two,
Well, it is already implemented by NoCem, and I find it quite
complementary with other anti-spam tools I use (diablo's built-in
anti-spam, and cleanfeed).
Problem is that anything that implies PGP is quite heavy (it requires
forking PGP) and therefore quite slow.
The idea behind NoCem is neat, but it should be implemented in a
lighter protocol, suitable for fast cancel in transit systems. I guess
that's what Matt has been talking about.
Now, to come back on the Cancel Lock issue, it is complementary to
the "fast-NoCem" approach : "fast-NoCem" is used to mass-cancel spam
messages, and "Cancel-Lock" is used to avoid rogue-cancels from
internet punks.
IMHO, both should be implemented.
--
Jean-Francois "Jef" Stenuit
Network operations manager
Belgacom Skynet
Rahul Dhesi
cryptographic header, for preventing unauthorized supersedes and
cancels.
With the X-Trace mechanism, we must seal out the use of fake X-Trace
headers at all sites that may inject News articles. Even if the primary
News routing software (inn, diablo, highwind) can be mde to do this,
there will always be other software running at small sites (typically
using NT) that will continue to allow arbitrary junk to be posted. Many
such sites will be injecting postings via ihave not via post, so their
upstream sites won't be able to compensate.
With a cryptographic mechanism in place, any site running updated
software will be immune to fake cancels acting on any article injected
using updated software. Software updates will immediately benefit all
sites using updated software, regardless of how many other sites are
using old software.
To illustrate:
Suppose by January 1, 1999 80% of all sites recognize authenticated
postings and cancels. All of these sites will be immune to fake cancels
of all postings originating from these sites. Nothing that the
remaining 20% sites do will defeat this.
On the other hand, the remaining 20% sites running old software can
easily defeat the use of X-Trace to authenticate cancels on all sites,
including on the 80% running new software.
Thus we see that the use of cryptographic authentication immediately
benefits sites using it, regardless of how many other sites are still
using old software. Thus sites have a strong incentive to upgrade their
software. The same strong incentive does not exist if X-Trace is used
for authentication, because each site now depends on every *other* site
also updating its software.
--
Rahul Dhesi <dh...@spams.r.us.com>
brian moore
Russ Allbery <r...@stanford.edu> wrote:
> And they are going to need *stronger* authentication than regular article
> cancels, should be batched, and ideally should have a clearly delegated
> chain of authority.
Almost sounds like NoCeM.
--
Brian Moore | "The Zen nature of a spammer resembles
Sysadmin, C/Perl Hacker | a cockroach, except that the cockroach
Usenet Vandal | is higher up on the evolutionary chain."
Netscum, Bane of Elves. Peter Olson, Delphi Postmaster
brian moore
> Ok, Lets put this on a more positive note and discuss a general solution
> to the problem.
>
> How about this. I could implement this in about three days for Diablo
> using the RSAREF library, inclusive of all the key-ring management
> functions.
Use non-patented technology. (Hint: you can't use RSA on a server
without paying a licensing fee.)
Diffie-Hellman's patent has expired.
--
Andrew Gierth
Andreas> I missed your argument against nocem.
NoCeM is not real-time.
NoCeM doesn't handle overlap between despammers efficiently.
NoCeM requires policy decisions on the part of the admin.
If NoCeM were sufficient for spam-removal, people wouldn't have asked
me for my cancels to be turned back on after the last moratorium.
--
Andrew.
Clayton O'Neill
|>>>>> "Andreas" == Andreas Barth <a...@muenchen.pro-bahn.org> writes:
|
| Andreas> I missed your argument against nocem.
|
|NoCeM is not real-time.
|NoCeM doesn't handle overlap between despammers efficiently.
|NoCeM requires policy decisions on the part of the admin.
This last one is bad how?
|If NoCeM were sufficient for spam-removal, people wouldn't have asked
|me for my cancels to be turned back on after the last moratorium.
I'd argue that people frequently don't know what's best for them. Not that
I know what's best for them either, but that's another issue.
brian moore
> :In article <slrn737t8...@thorin.cmc.net>,
> :brian moore <b...@news.cmc.net> wrote:
> :> Matt Dillon <dil...@best.net> wrote:
> :>> Ok, Lets put this on a more positive note and discuss a general solution
> :>> to the problem.
> :>>
> :>> How about this. I could implement this in about three days for Diablo
> :>> using the RSAREF library, inclusive of all the key-ring management
> :>> functions.
> :>Use non-patented technology. (Hint: you can't use RSA on a server
> :>without paying a licensing fee.)
> :>
> :>Diffie-Hellman's patent has expired.
>
> isn't commercial (i.e. sold for money), you can use it.
Really?
Looks like it says:
1. You can use RSAREF in personal, non-commercial applications,
as long as you follow the interface described in the RSAREF
documentation. You can't use RSAREF in any commercial
(moneymaking) manner of any type, nor can you use it to
provide services of any kind to any other party. For
information on commercial licenses of RSAREF-compatible
products, please contact RSA Data Security. (Special
arrangements are available for educational institutions and
non-profit organizations.)
Now perhaps, that's just the laymen's terms at the beginning.
Is your news server personal and non-commercial? Do you really run a
news server sucking multi-T1's as a 'personal, non-commercial
application'?
Or we can look at the RSA Data Security web page at question 6.3.1 of
their own FAQ:
Question 6.3.1.
Is RSA patented?
RSA is patented under U.S. Patent 4,405,829, issued September 29, 1983
and held by RSA Data Security, Inc.; the patent expires 17 years after
issue, in the year 2000. RSA Data Security has a standard,
royalty-based licensing policy, which can be modified for special
circumstances. The U.S. government can use RSA without a license
because it was invented at MIT with partial government funding.
In the U.S., a license is needed to make, use or sell RSA. However,
RSA Data Security usually allows free non-commercial use of RSA, with
written permission, for academic or university research purposes.
Now, I dunno about you, but I really don't think a .com or .net based
news server would count as "academic or university research purposes"
and thus get the 'free non-commercial use' license.
Now, the legalese from the license:
b. The Program and all Application Programs are to be used only
for non-commercial purposes. However, media costs associated
with the distribution of the Program or Application Programs
may be recovered.
Is a news server non-commercial?
Now, yes, you could probably argue that 'diablo' itself is
non-commercial and distribute it with your RSAREF hooks: but using it
with RSAREF on anything but a personal system would be a violation of
the license. Anyone that didn't want to be fined wouldn't run it.
Again, Diffie-Hellman is patent free: patent 4,200,770 expired last
year.
RSA has a patent for a couple more years and RSA Data Security is
unbending in their restrictions.
Rahul Dhesi
> Hmmm... ok, so what do we use if we can't use RSA ? I'd prefer not
> to have to use PGP.
I found free encryption modules, including El Gamal, in various
languages, at www.systemics.com. I was not able to get the perl modules
to compile with gcc under SunOS. But maybe others who are smarter than
I am can extract some code, get permission from the authors, and use El
Gamal.
--
Rahul Dhesi <dh...@spams.r.us.com>
Clayton O'Neill
|Clayton O'Neill <use...@oneill.net> wrote:
|> |sense of security. Do you actually believe the Sender header? If not,
|> |why do you think you could believe an X-Trace header? Okay, I do
|> |believe an X-Trace header _if_ I know the sending site is running a
|> |recent INN and I can verify from the Path header that the sending site
|> |is in fact the sending site...
|
|> I trust our X-Trace headers since we've recently moved to encrypting
| ^ ^^^
|> them. This preserves the privacy of our customers and also
|> guarantees that complaints we get are actually our users and not
|> forgeries.
|
|That's fine, I trust my X-Trace headers too, more so since I have
|access to the logs to correlate them. The question is, how could
|_other_ sites trust my or your X-Trace? Short answer: they can not, in
|general.
Agreed, I wasn't arguing in favor of Matt's proposal. I was just pointing
out that there are other implementations of X-Trace. Several other
providers do similar implementations. I'd actually like to see the above
code integrated into INN, but I don't want to get into the cesspool of
encryption and encryption hooks.
BTW, can anyone point me at a good public domain implementation of SHA1
that's endian independent? I'm very tempted to write the code for INN to
make Cancel-Lock and Cancel-Key verification work. I'll bet money they it's
less than 50 new lines of code, probably closer to 10-20.
Michael Herrmann
> Hmmm... ok, so what do we use if we can't use RSA ? I'd prefer not
> to have to use PGP.
I think we can. Take a look at SSLeay at http://www.cryptsoft.com/.
It's a excellent free library for all sorts of crypto-stuff from
australia (no export restrictions) and I think it can be used with
RSAref for use inside the US. If using its own RSA implementation
it's way faster than RSAref, BTW.
Michael
brian moore
> Hmmm... ok, so what do we use if we can't use RSA ? I'd prefer not
> to have to use PGP.
Diffie-Hellman, specifically ElGamal.
I can even point you at a C implementation that's GPL'd:
http://www.d.shuttle.de/isil/gnupg/
Andreas Barth
> BTW, can anyone point me at a good public domain implementation of SHA1
> that's endian independent? I'm very tempted to write the code for INN to
> make Cancel-Lock and Cancel-Key verification work. I'll bet money they it's
> less than 50 new lines of code, probably closer to 10-20.
Take a look at http://members.tripod.com/~gerglery/
There are implementations of canlock for inn, slrn and tin. I don't know
if that's what you're looking for.
Andreas Barth
> If NoCeM were sufficient for spam-removal, people wouldn't have asked
> me for my cancels to be turned back on after the last moratorium.
If you install inn from e.g. Redhat-Linux, you won't get nocem. The same
is AFAIK valid for most others Distributions and operating systems.
Cancels are supported from the start. So most people are just ignoring
NoCeM.
What to do? Just include NoCeM in the main software distributions, like
cleanfeed now, and it would work. I'm thinking about publishing nocem and
canlock-rpms for Redhat-Linux, to ease installation.
bill davidsen
Russ Allbery <r...@stanford.edu> wrote:
| You've just described cancel locks, which Matt describes as a stupid idea.
| A lot of the rest of us disagree with him on that. :)
|
| <URL:ftp://ftp.isi.edu/internet-drafts/draft-ietf-usefor-cancel-lock-00.txt>
Cancel locks without a a sysadmin override are not practical, either.
They simply allow spammers to prevent control of their spew.
There are two parts to the cancel problem, the problem of unauthorized
cancels of legitimate posts, which we would prevent, and the problem of
authenticated cancels of spam, which we need for a usable usenet.
In my version of a perfect world, a post could be canceled by the
author, the insertion site, and entities which sites may choose to
accept as authoratative. And no one else.
Locally cancled, too, obviously.
--
bill davidsen <davi...@tmr.com> CTO, TMR Associates, Inc
The young confuse living a long time with getting old,
the old confuse age with maturity.
Matt Dillon
:>Matt Dillon <dil...@best.net> wrote:
:..
:>
:>I fail to see in which way this is different from the Cancel-Lock mechanism.
:>
:>(Other than that it uses a much more compute-intensive algorithm and
:>needs a PK infrastructure.)
:>
:>olaf
Then haven't read it carefully. Cancel-Lock covers one specific case
in the news system.
The above header idea is integrated with the other two and covers the
*entire* news system infrastructure. Not just a tiny piece of it.
(and, in fact, I don't even need to distribute the private key there,
I can just sign that one header with the private key).
*BIG* difference.
Andrew Gierth
>> If NoCeM were sufficient for spam-removal, people wouldn't have asked
>> me for my cancels to be turned back on after the last moratorium.
Olaf> None of my users has ever asked me to do so... in fact, I have had
Olaf> cancels off for a long time.
I wasn't talking about users (fortunately, I don't have any of those),
I meant that there were *admins* asking me to resume cancelling in
addition to NoCeM generation.
--
Andrew.
Andrew Gierth
Matt> Here's take two. Capable of great complexity but simply
Matt> implemented.
This is starting to look promising. Have you looked at Brad Templeton's
ideas along similar lines?
Matt> X-DPkeAway: I=identifier F=format S=signature
Matt> May be used in cancels, supersedes, or any article which creates a
Matt> side effect on some other article. Allows a user or administrator
Matt> to sign postings with a random key. If the user then wishes to
Matt> override (cancel or supersede) the posting, he can sign the header
Matt> with the private key associated with the identifier.
This one I don't like. RSA-type keys are way too heavyweight for a
cancel-lock type system (which is what this sounds like).
Why is it necessary, in any case? For cancels/supersedes, if the
original article was signed by either the poster or the originating
site, then signing the cancel with the same key is sufficient.
(There are two schools of thought regarding cancel locks. One is that
since a public-key system is necessary for handling third-party cancels,
that makes a non-public-key cancel-lock system redundant. The other is
that a cancel-lock system is useful anyway.)
--
Andrew.
bill davidsen
Clayton O'Neill <use...@oneill.net> wrote:
| I trust our X-Trace headers since we've recently moved to encrypting them. This
| preserves the privacy of our customers and also guarantees that complaints
| we get are actually our users and not forgeries.
What?!!
Why bother to have it? All you do is ensure that if I post from your
site and forge a few headers that there will be no way to trace a post
back to the injection point.
Sounds like a spammer trick, not a security measure, the major effect is
to prevent tracking of objectionable material, why you want to be able
to deny that you are the injection site, or hide the time and place of
posting is beyond me.
This sure doesn't sound like something I would expect to see from you...
I would expect you to be raging that we should drop these faulty
headers, and that doesn't sound like a bad idea. X-Trace is a finger
pointing back to the point of origin, and I can't see any benefit to
hiding it.
Matt Dillon
:>Matt Dillon <dil...@best.net> wrote:
:>>
:>> Nonsense. Why ?
:>
:>If everyone on Usenet needs a PGP key in order for ther system to
:>work, how do those millions of keys get into every server 'round the
:>world? And how will any current hardware be able to perform 100,000
:>PGP signature verifications a day in addition to the usual news server
:>loads?
:>
:>olaf
Olaf, will you please at least read my fragg'n postings? They cover
this. Your posting of this question only indicates that either you
haven't bothered to read the postings, or you don't understand them.
Matt Dillon
:bill davidsen <davi...@tmr.com> wrote:
:>In article <slrn736k9u...@hmmm.colo.erols.net>,
Giganews does the same thing... it pisses me off to no end. Crypting
X-Trace doesn't help anyone but the spammers.
Matt Dillon
:Andrew Gierth <and...@erlenstar.demon.co.uk> wrote:
:>>>>>> "Matt" == Matt Dillon <dil...@best.net> writes:
:>
:> Matt> Here's take two. Capable of great complexity but simply
:> Matt> implemented.
:>
:>This is starting to look promising. Have you looked at Brad Templeton's
:>ideas along similar lines?
:>
:> Matt> X-DPkeAway: I=identifier F=format S=signature
:>
:> Matt> side effect on some other article. Allows a user or administrator
:> Matt> to sign postings with a random key. If the user then wishes to
:> Matt> override (cancel or supersede) the posting, he can sign the header
:> Matt> with the private key associated with the identifier.
:>
:>This one I don't like. RSA-type keys are way too heavyweight for a
:>cancel-lock type system (which is what this sounds like).
:>
:>Why is it necessary, in any case? For cancels/supersedes, if the
:>original article was signed by either the poster or the originating
:>site, then signing the cancel with the same key is sufficient.
:>
:>(There are two schools of thought regarding cancel locks. One is that
:>since a public-key system is necessary for handling third-party cancels,
:>that makes a non-public-key cancel-lock system redundant. The other is
:>that a cancel-lock system is useful anyway.)
:>
:>--
:>Andrew.
Brad and I have been exchanging emails. We are both on the same track,
pretty much, but there are some operational differences.
RSA has its own problems, for sure, and in fact I've already changed that
part of the spec... there is no need to send a private key, you need only
sign the header. This just leaves the public key. It's kinda interesting
that in this case it is the private postings that wind up being more
bulky... the control messages do not need to include their public key,
they are simply signed and the keys are propogated and stored separately.
The real sticking point is finding a free crypto library that can be
used in the core. I suppose I could always just implement one myself,
but I would prefer not to spend the week it would require to do so.
-Matt
Clayton O'Neill
|In article <slrn736k9u...@hmmm.colo.erols.net>,
|Clayton O'Neill <use...@oneill.net> wrote:
|
|| I trust our X-Trace headers since we've recently moved to encrypting them. This
|| preserves the privacy of our customers and also guarantees that complaints
|| we get are actually our users and not forgeries.
|
|What?!!
|
|Why bother to have it? All you do is ensure that if I post from your
|site and forge a few headers that there will be no way to trace a post
|back to the injection point.
|
|Sounds like a spammer trick, not a security measure, the major effect is
|to prevent tracking of objectionable material, why you want to be able
|to deny that you are the injection site, or hide the time and place of
|posting is beyond me.
|
|This sure doesn't sound like something I would expect to see from you...
|I would expect you to be raging that we should drop these faulty
|headers, and that doesn't sound like a bad idea. X-Trace is a finger
|pointing back to the point of origin, and I can't see any benefit to
|hiding it.
Look at my headers, we add a X-Trace header and a X-Complaints-To header.
We also each of our machines pathstamp. We no longer add a
NNTP-Posting-Host, NNTP-Posting-Host-Date or Sender header on articles since
the X-Trace header contains a copy of all that data.
How does this change the picture?
AFAICT, what we've done allows you to tell that one of our users did it, but
not who did it. If you provide us with the Message-ID and the X-Trace
header then we can verify who did it and when w/o a doubt about whether or
not the post was forged. I consider that a step forward, not backwards.
Thoughts?
Clayton O'Neill
| Giganews does the same thing... it pisses me off to no end. Crypting
| X-Trace doesn't help anyone but the spammers.
How do you figure that it helps spammers? We still add an X-Complaints-To
header that clearly indicates that it's one of ours.
Matt Dillon
:Rahul Dhesi <c.c....@78.usenet.us.com> wrote:
:>In <7119lc$fth$1...@flea.best.net> dil...@best.net (Matt Dillon) writes:
:>
:>> Hmmm... ok, so what do we use if we can't use RSA ? I'd prefer not
:>> to have to use PGP.
:>I found free encryption modules, including El Gamal, in various
:>languages, at www.systemics.com. I was not able to get the perl modules
:>to compile with gcc under SunOS. But maybe others who are smarter than
:>I am can extract some code, get permission from the authors, and use El
:>Gamal.
:>--
:>Rahul Dhesi <dh...@spams.r.us.com>
This looks *very* promising. Their license covers both commercial
and non-commercial use. Unfortunately it appears to be 100% java.
Matt Dillon
:Michael Herrmann <m...@pobox.com> wrote:
:>dil...@best.net (Matt Dillon) writes:
:>
:>> Hmmm... ok, so what do we use if we can't use RSA ? I'd prefer not
:>> to have to use PGP.
:>
:>It's a excellent free library for all sorts of crypto-stuff from
:>australia (no export restrictions) and I think it can be used with
:>RSAref for use inside the US. If using its own RSA implementation
:>it's way faster than RSAref, BTW.
:>
:>Michael
This looks quite promising.
Andrew Gierth
Matt> Used to sign a normal posting or control message. There are
Matt> no guard characters. The specified headers and body (if
Matt> included) must be 8-bit clean. This also means that the
Matt> article body must terminate with an LF prior to escaping. The
Matt> 8-bit clean article must be '.' and LF->CRLF escaped by the
Matt> NNTP protocol and de-escaped (remove '.' and CRLF ->LF) on the
Matt> remote side. An article containing CR's in de-escaped form is
Matt> allowed but must be properly escaped/deescaped,
Matt> i.e. CRLF->CRCRLF and CRCRLF->CRLF.
I think you need to rewrite this bit in terms of the article
definition in the USEFOR drafts.
--
Andrew.
Matt Dillon
X-Trace: sv1-tjfLYUJ/AhuACi/9qmigEETX2QiLgboKnYTH9TDhH0+vIEx3HzZJVGuKcj/47/l0m0RA/Zrgb6wHMzD!zpd35Icb
X-Complaints-To: ab...@GigaNews.Com
It makes it impossible to identify the spammer, requiring that complaints be
sent to giganews instead of directly to the spammer's ISP. This alone
gives the spammers a HUGE leg-up. Do you think giganews has more pull
with the spammer's ISP then, say, I do? Do you think that ISP is going
to care getting a few complaints from a giganews admin verses getting
hundreds of complaints from individuals ?
It makes it impossible to identify postings coming from the same source.
It fucks up any attempt at doing rate filtering. It's bad enough that
NNTP-Posting-Host (one of the few headers that cannot be widely spoofed)
was removed, but crypting X-Trace: takes the cake.
I am seriously pissed at giganews.
Matt Dillon
:>|In article <slrn736k9u...@hmmm.colo.erols.net>,
:>How does this change the picture?
:>AFAICT, what we've done allows you to tell that one of our users did it, but
:>not who did it. If you provide us with the Message-ID and the X-Trace
:>header then we can verify who did it and when w/o a doubt about whether or
:>not the post was forged. I consider that a step forward, not backwards.
:>
:>Thoughts?
I don't give a fucking damn what it allows you to do... it restricts what
we other admins can do to the point where it is generally not worth it
to even pursue the spammers. Indirect spam complaints DO NOT WORK. If
we can't complain directly to the spammer's provider, the spammer will
have basically won because (a) the spammer's ISP doesn't get as many
complaints as it would otherwise, and (b) the shutdown of the spammer's
account takes longer to accomplish.. much longer on weekends. Do you
have people manning the phones 24 hours a day? Are they willing to
*call up* the offending ISP right then and there?
Giganews is fucked in the head if they think crypting X-Trace helps anyone.
Clayton O'Neill
|:In article <slrn73a76i...@luser.oneill.net>,
|:>| Giganews does the same thing... it pisses me off to no end. Crypting
|:>| X-Trace doesn't help anyone but the spammers.
|:>
|:>How do you figure that it helps spammers? We still add an X-Complaints-To
|:>header that clearly indicates that it's one of ours.
|
| X-Trace: sv1-tjfLYUJ/AhuACi/9qmigEETX2QiLgboKnYTH9TDhH0+vIEx3HzZJVGuKcj/47/l0m0RA/Zrgb6wHMzD!zpd35Icb
| X-Complaints-To: ab...@GigaNews.Com
|
| It makes it impossible to identify the spammer, requiring that complaints be
| sent to giganews instead of directly to the spammer's ISP. This alone
| gives the spammers a HUGE leg-up. Do you think giganews has more pull
| with the spammer's ISP then, say, I do? Do you think that ISP is going
| to care getting a few complaints from a giganews admin verses getting
| hundreds of complaints from individuals ?
Giganews is different case from us because they resell to ISP's, but
regardless, they are ultimately responsible for the spam that's posted
through their servers, I'd expect that they take care of it or they'll end
up being filtered.
| It makes it impossible to identify postings coming from the same source.
This is part of the point. There is something to be said for anonymity and
privacy. We're willing to take responsiblity for people that spam through
us and take appropriate action when it happens. There is nothing you can do
about people spamming through us other than report them to us. We have a
fairly good track record with respect to cancelling spammers.
| It fucks up any attempt at doing rate filtering. It's bad enough that
| NNTP-Posting-Host (one of the few headers that cannot be widely spoofed)
| was removed, but crypting X-Trace: takes the cake.
There are already enough servers out there that don't insert
NNTP-Posting-Host that it's fairly easy to forge. One of the reasons we
went to encrypting X-Trace is that we can verify that the data in there is
not forged.
| I am seriously pissed at giganews.
And not at Newscene?
Clayton O'Neill
|:In article <slrn73a70p...@luser.oneill.net>,
|:>|In article <slrn736k9u...@hmmm.colo.erols.net>,
|:>
|:>How does this change the picture?
|:>
|:>AFAICT, what we've done allows you to tell that one of our users did it, but
|:>not who did it. If you provide us with the Message-ID and the X-Trace
|:>header then we can verify who did it and when w/o a doubt about whether or
|:>not the post was forged. I consider that a step forward, not backwards.
|:>
|:>Thoughts?
|
| I don't give a fucking damn what it allows you to do... it restricts what
| we other admins can do to the point where it is generally not worth it
| to even pursue the spammers. Indirect spam complaints DO NOT WORK. If
| we can't complain directly to the spammer's provider, the spammer will
| have basically won because (a) the spammer's ISP doesn't get as many
| complaints as it would otherwise, and (b) the shutdown of the spammer's
| account takes longer to accomplish.. much longer on weekends. Do you
| have people manning the phones 24 hours a day? Are they willing to
| *call up* the offending ISP right then and there?
No, but as far as I know, we've not sold net access to any resellers, so any
spam complaints have to come through our abuse department for anything to
happen anyway.
| Giganews is fucked in the head if they think crypting X-Trace helps anyone.
I think it's fairly easily demonstrated that it helps end-user privacy.
Regardless, we're not Giganews.
bill davidsen
Clayton O'Neill <use...@oneill.net> wrote:
| On 26 Oct 1998 19:08:56 GMT, bill davidsen <davi...@tmr.com> wrote:
| |In article <slrn736k9u...@hmmm.colo.erols.net>,
| |Clayton O'Neill <use...@oneill.net> wrote:
| Look at my headers, we add a X-Trace header and a X-Complaints-To header.
| We also each of our machines pathstamp. We no longer add a
| NNTP-Posting-Host, NNTP-Posting-Host-Date or Sender header on articles since
| the X-Trace header contains a copy of all that data.
|
| How does this change the picture?
You are hiding all the data which would remotely let a human see where
the post originates. So if I see spam with this non-info I can just send
off a note to the abuse address which might be a black hole unrelated to
the injection process.
You have disavowed more knowledge than _Mission Impossible_.
| AFAICT, what we've done allows you to tell that one of our users did it, but
| not who did it. If you provide us with the Message-ID and the X-Trace
| header then we can verify who did it and when w/o a doubt about whether or
| not the post was forged. I consider that a step forward, not backwards.
Let's look at your original post for an example of confusion... the from
address is in oneill.net, the abuse address is in rcn.com, the
message-id is from erols.net, and the first site in the path is rcn.net.
With a valid X-Trace header it would be obvious what really happened,
while all the conflicting information is not condusive to more than an
educated guess.
| Thoughts?
Anyone who looks at my posts certainly sees a lot of odd info, posting
from multiple connected and dialup points, via PVN to machines inside
firewalls and owned by multiple corporations. But the X-Trace at least
is a real indication of the injection point and the machine on which the
reader software executed. The fact that I run in a terminal from
elsewhere over a PVN is not visible, nor is it relevant. I'm not
complaining because you use networking creatively.
But as far as I can tell the X-Trace was supposed to provide a solid
pointer back to the point of origin, without depending on the vagaries
of admins who may be incompetent, uncooperative, or just overworked. The
information in a correctly formed X-Trace header is not sensitive; it
can be traced to the originating site but not the user. I don't see any
reasons to hide it, at least not for a legitimate site.
bill davidsen
Clayton O'Neill <use...@oneill.net> wrote:
| There are already enough servers out there that don't insert
| NNTP-Posting-Host that it's fairly easy to forge. One of the reasons we
| went to encrypting X-Trace is that we can verify that the data in there is
| not forged.
You couldn't look up the message-id and see if it's one of yours? Why
not? You don't care if it's forged, and you can tell if it's yours even
if it is.
And if someone spams and puts your abuse and x-trace info in the spam,
you will still be blamed. Just what have you really gained?
Rahul Dhesi
> X-Trace: sv1-tjfLYUJ/AhuACi/9qmigEETX2QiLgboKnYTH9TDhH0+vIEx3HzZJVGuKcj/47/l0m0RA/Zrgb6wHMzD!zpd35Icb
> X-Complaints-To: ab...@GigaNews.Com
> It makes it impossible to identify the spammer, requiring that complaints be
> sent to giganews instead of directly to the spammer's ISP. This alone
> gives the spammers a HUGE leg-up. Do you think giganews has more pull
> with the spammer's ISP then, say, I do? Do you think that ISP is going
> to care getting a few complaints from a giganews admin verses getting
> hundreds of complaints from individuals ?
This is the same strategy that UUNET uses to protects its spamming users,
while still arguing that it's antispam.
--
Rahul Dhesi <dh...@spams.r.us.com>
Clayton O'Neill
|You are hiding all the data which would remotely let a human see where
|the post originates. So if I see spam with this non-info I can just send
|off a note to the abuse address which might be a black hole unrelated to
|the injection process.
I think it's fairly clear from the X-Complaints-To header where
administrative responsiblity lies, but if you're in doubt, feel free to send
mail to all the above addresses.
|You have disavowed more knowledge than _Mission Impossible_.
|
|| AFAICT, what we've done allows you to tell that one of our users did it, but
|| not who did it. If you provide us with the Message-ID and the X-Trace
|| header then we can verify who did it and when w/o a doubt about whether or
|| not the post was forged. I consider that a step forward, not backwards.
|
|Let's look at your original post for an example of confusion... the from
|address is in oneill.net, the abuse address is in rcn.com, the
|message-id is from erols.net, and the first site in the path is rcn.net.
|With a valid X-Trace header it would be obvious what really happened,
|while all the conflicting information is not condusive to more than an
|educated guess.
Message-ID is generated by the client which lies in erols.net. It happens
to be a box colocated at RCN. The oneill.net address is my vanity domain
and is added by the client also. It's fairly clear from the whois data that
rcn.com and rcn.net are the same adminstrative entity. What part of this
message wouldn't have been faked in a spam? All of them could have been
forged.
How is the X-Trace header any more indicative than X-Complaints-To? Why
would you care which server it's posted to as long as you know where to
complain to about it?
|Anyone who looks at my posts certainly sees a lot of odd info, posting
|from multiple connected and dialup points, via PVN to machines inside
|firewalls and owned by multiple corporations. But the X-Trace at least
|is a real indication of the injection point and the machine on which the
|reader software executed. The fact that I run in a terminal from
|elsewhere over a PVN is not visible, nor is it relevant. I'm not
|complaining because you use networking creatively.
|
|But as far as I can tell the X-Trace was supposed to provide a solid
|pointer back to the point of origin, without depending on the vagaries
|of admins who may be incompetent, uncooperative, or just overworked. The
|information in a correctly formed X-Trace header is not sensitive; it
|can be traced to the originating site but not the user. I don't see any
|reasons to hide it, at least not for a legitimate site.
As far as I can tell, the X-Complaints-To header provides a solid pointer
back to the people that are responsible for handling any complaints about
abuse, etc. My understanding (and what we've used it for here) is that
X-Trace was to allow people handling the complaints to track down the
parties responsible.
The issue of privacy arose when we started allowing nntp authenticated
connections by our uses from outside of our network. We had reason to
believe (based on complaints we recieved when we started adding X-Trace &
X-Complaints-To) that forcing the Sender header would cause much alarm in
our userbase about privacy concerns. We had to have some way to track back
abusive users without divulging account information to the world at large.
This is basically what we ended up with.
Clayton O'Neill
|In article <slrn73a95b...@luser.oneill.net>,
|Clayton O'Neill <use...@oneill.net> wrote:
|
|| There are already enough servers out there that don't insert
|| NNTP-Posting-Host that it's fairly easy to forge. One of the reasons we
|| went to encrypting X-Trace is that we can verify that the data in there is
|| not forged.
|
|You couldn't look up the message-id and see if it's one of yours? Why
|not? You don't care if it's forged, and you can tell if it's yours even
|if it is.
Sure, but the X-Trace information includes a signature of the message-id, so
that we can try to avoid replay attacks.
|And if someone spams and puts your abuse and x-trace info in the spam,
|you will still be blamed. Just what have you really gained?
We can determine based on the above information whether or not the post is
really ours. If people chose not to believe us then I don't know why they'd
believe the headers either.
Rahul Dhesi
O'Neill) writes:
>The issue of privacy arose when we started allowing nntp authenticated
>connections by our uses from outside of our network. We had reason to
>believe (based on complaints we recieved when we started adding X-Trace &
>X-Complaints-To) that forcing the Sender header would cause much alarm in
>our userbase about privacy concerns. We had to have some way to track back
>abusive users without divulging account information to the world at large.
Revealing a login name should not be considered a violation of privacy.
The user is always free to pick a login name not related to his real
name.
--
Rahul Dhesi <dh...@spams.r.us.com>
Clayton O'Neill
Perhaps it _should_ not, but a vocal portion of our user base considers it
to be one. I can't think of a real need to put that information in plain
text in the header.
Jeremy
> I don't give a fucking damn what it allows you to do... it restricts
> what we other admins can do to the point where it is generally not
> worth it to even pursue the spammers. Indirect spam complaints DO NOT
> WORK. If we can't complain directly to the spammer's provider, the
> spammer will have basically won because (a) the spammer's ISP doesn't
> get as many complaints as it would otherwise, and (b) the shutdown of
> the spammer's account takes longer to accomplish.. much longer on
> weekends. Do you have people manning the phones 24 hours a day? Are
> they willing to *call up* the offending ISP right then and there?
>
> Giganews is fucked in the head if they think crypting X-Trace helps
> anyone.
We do much the same thing at Supernews. There are no posting-host
headers, though the user cannot supply one. (They are present on posts
from outsourced ISPs.) We can identify a user with the X-Trace header.
In the case of an individual account user, *we* are the provider. If
they spam, *we* are responsible for that, and the complaint should go to
us. There is *no* reason for us to stamp an article with where the user
is connecting from. People want privacy, so we give it to them.
--
Jeremy | jer...@exit109.com
"Who's scruffy-looking?" --Han Solo
Andrew Gierth
Clayton> Look at my headers, we add a X-Trace header and a
Clayton> X-Complaints-To header.
Neither of these are useful for generating spam complaints. (Bogus
X-Complaints-To lines are common, either added by spammers or
undeliverable email addresses added by misconfigured sites.)
Clayton> We also each of our machines pathstamp.
What do you do, if anything, about preloaded paths?
--
Andrew.
Clayton O'Neill
|>>>>> "Clayton" == Clayton O'Neill <use...@oneill.net> writes:
|
| Clayton> Look at my headers, we add a X-Trace header and a
| Clayton> X-Complaints-To header.
|
|Neither of these are useful for generating spam complaints. (Bogus
|X-Complaints-To lines are common, either added by spammers or
|undeliverable email addresses added by misconfigured sites.)
Does someone have a better suggestion then? All of the headers we're
discussing are easily forged anyway.
|
| Clayton> We also each of our machines pathstamp.
|
|What do you do, if anything, about preloaded paths?
Not much we can do about them w/o breaking loop detection.
Jeremy
> In <slrn73aamp...@luser.oneill.net> use...@oneill.net (Clayton
> O'Neill) writes:
>
>> The issue of privacy arose when we started allowing nntp authenticated
>> connections by our uses from outside of our network. We had reason
>> to believe (based on complaints we recieved when we started adding
>> X-Trace & X-Complaints-To) that forcing the Sender header would cause
>> much alarm in our userbase about privacy concerns. We had to have
>> some way to track back abusive users without divulging account
>> information to the world at large.
>
> Revealing a login name should not be considered a violation of privacy.
Tell that to the users.
Heck, *I* don't even agree with that. If I want to post without
revealing my identity with my real address, why should I not be able
to do so?
--
Jeremy | jer...@exit109.com
"The sky would not fall if an American President spoke the truth."
--Ronald Reagan
Matt Dillon
:>|:In article <slrn73a76i...@luser.oneill.net>,
:>
:>And not at Newscene?
Newscene is almost as bad as alt.net ... but there's a solution to
sites that effectively promote abuse and don't stop (or control) attacks
made through their systems. It's called a pathalias.
Giganews isn't as bad, at least not bad enough to be pathaliased out.
Almost bad enough to not transit, though. But they are still pretty bad.
This is why I'm pissed.
Matt Dillon
:>|In <slrn73aamp...@luser.oneill.net> use...@oneill.net (Clayton
:>|O'Neill) writes:
:>|
:>|>The issue of privacy arose when we started allowing nntp authenticated
:>|>connections by our uses from outside of our network. We had reason to
:>|>believe (based on complaints we recieved when we started adding X-Trace &
:>|>X-Complaints-To) that forcing the Sender header would cause much alarm in
:>|>our userbase about privacy concerns. We had to have some way to track back
:>|>abusive users without divulging account information to the world at large.
:>|
:>|Revealing a login name should not be considered a violation of privacy.
:>|name.
:>
:>Perhaps it _should_ not, but a vocal portion of our user base considers it
:>to be one. I can't think of a real need to put that information in plain
:>text in the header.
The motives of the large news-specific providers are clear: They are more
interested in the revenue flow then on the effect their users have on the
rest of the USENET.
You certainly do not need to put the user id in the X-Trace... the IP
address will do just fine. It gives most users appropriate anonymity
(since they typically come in on a dynamic IP anyway) while also giving
admins the ability to complain to the correct source.
Andrew Gierth
> |Neither of these are useful for generating spam complaints. (Bogus
> |X-Complaints-To lines are common, either added by spammers or
> |undeliverable email addresses added by misconfigured sites.)
Clayton> Does someone have a better suggestion then? All of the
Clayton> headers we're discussing are easily forged anyway.
NNTP-Posting-Host is the least forgeable and most reliable when
dealing with spam (though somewhat less so when dealing with flooding,
cancelbombing, and other more advanced forms of abuse).
The only spammer who has presented a serious problem of forgery of
NNTP-Posting-Host has been the Empire Communications / AJV operation
(Matt Middleton, Andy Vilcus/Vilcauskas & Rob Bloodgood, aliases
"David Shultz", various others I don't recall, domains nwregion.net,
hostcomm.net, pdxfiber.net, poshnet.com, pacstar.net, 123adult.com
etc. etc.), who I see *still* have connectivity though Verio NW.
Preloaded paths, on the other hand, crop up with annoying regularity.
Clayton> Not much we can do about them w/o breaking loop detection.
Several options:
- add a path entry to articles POSTed to you, independently of your
normal path stamp(s) on transit traffic
- reject POSTs with a ! in the path
- add a header on POST with X-Posted-Path-Was or some such
--
Andrew.
Clayton O'Neill
|:In article <slrn73a95b...@luser.oneill.net>,
|:>|:In article <slrn73a76i...@luser.oneill.net>,
|:>
|:>And not at Newscene?
|
| Newscene is almost as bad as alt.net ... but there's a solution to
| sites that effectively promote abuse and don't stop (or control) attacks
| made through their systems. It's called a pathalias.
|
| Giganews isn't as bad, at least not bad enough to be pathaliased out.
| Almost bad enough to not transit, though. But they are still pretty bad.
| This is why I'm pissed.
Any comments on the other points?
Rahul Dhesi
O'Neill) writes:
>|Revealing a login name should not be considered a violation of privacy.
>|The user is always free to pick a login name not related to his real
>|name.
>Perhaps it _should_ not, but a vocal portion of our user base considers it
>to be one. I can't think of a real need to put that information in plain
>text in the header.
To an extent it's a philosphical thing. Many people like to create
multiple identities, and this is easy to do by using free email
providers such as hotmail and posting anonymously. This allows the
person to be obnoxious on Usenet (without exceeding the limits imposed
by his ISP, which limits tend to be quite generous in most cases). Once
everybody killfiles one identity, a new one can be trivially created.
I personally think that if a person wants multiple identities, he ought
to get multiple accounts and pay for each. This way there is a cost to
getting killfiled, which discourages obnoxious behavior.
Either way, there is no violation of privacy. Arguments claiming
otherwise have no merit.
--
Rahul Dhesi <dh...@spams.r.us.com>
Matt Dillon
:>|>>>>> "Clayton" == Clayton O'Neill <use...@oneill.net> writes:
:>|
:>| Clayton> Look at my headers, we add a X-Trace header and a
:>| Clayton> X-Complaints-To header.
:>|
:>|Neither of these are useful for generating spam complaints. (Bogus
:>|X-Complaints-To lines are common, either added by spammers or
:>|undeliverable email addresses added by misconfigured sites.)
:>Does someone have a better suggestion then? All of the headers we're
:>discussing are easily forged anyway.
People keep on saying that, but it isn't really true. While it is
possible to forge these headers on many systems, it is NOT possible to
forge them on systems that support the headers. That's the whole point.
It's generally pretty easy for a human to determine whether a posting came
from a system that supports X-Trace or not, because the Path: line
typically has extra elements tacked onto the end of an nntp reader host.
As with most tracking mechanisms, you don't get perfection but you
do get something that works well enough to cover the vast majority of
the abuse that does occur.
Afterburner
> The motives of the large news-specific providers are clear: They are more
> interested in the revenue flow then on the effect their users have on the
> rest of the USENET.
I think I'm stirring testimonial to the contrary.
(Granted: We at RCN want your money. We're funny that way. Most
businesses are. But the Erol's Higher-Ups(tm) were clever enough to put me
in charge of ab...@erols.com, and the RCN Higher-Ups(tm) seem to be clever
enough not to fuck with a good thing, and they are, in fact, putting me in
charge of all RCN abuse issues.)
The rest of your doubtlessly fine and well-reasoned points are over
my head, but I couldn't let the "Those Evil Capitalist ISPs!" argument go
without some commentary.
Yours,
Afterburner
RCN Abuse Guy
Matt Dillon
:Jeremy <jer...@exit109.com> wrote:
:>Matt Dillon <dil...@best.net> wrote:
:>
:>> I don't give a fucking damn what it allows you to do... it restricts
:>
:>We do much the same thing at Supernews. There are no posting-host
:>headers, though the user cannot supply one. (They are present on posts
:>from outsourced ISPs.) We can identify a user with the X-Trace header.
:>
:>In the case of an individual account user, *we* are the provider. If
:>they spam, *we* are responsible for that, and the complaint should go to
:>us. There is *no* reason for us to stamp an article with where the user
:>is connecting from. People want privacy, so we give it to them.
:>
:>--
:>Jeremy | jer...@exit109.com
:>"Who's scruffy-looking?" --Han Solo
With few exceptions, the people that scream about privacy are the same
people who tend to abuse the USENET. They want privacy so they don't
get kicked off their ISPs as often as they would otherwise.
Handing out an IP address that is more then likely a dynamic PPP dialup
does not throw away privacy, but it does prevent complaints from getting
to where they need to go. It isn't YOU that we are interested in...
the user can simply rotate between news providers. It's the user's
ISP that we are interested in. While it is still relatively easy for
a user to jump ISPs, it costs them a lot more to do so then to jump
news providers.
Jeremy
> You certainly do not need to put the user id in the X-Trace... the IP
> address will do just fine. It gives most users appropriate anonymity
> (since they typically come in on a dynamic IP anyway) while also giving
> admins the ability to complain to the correct source.
But the correct source is the Usenet provider.
--
Jeremy | jer...@exit109.com
"...your brain recognizes the pattern of light and dark made by a
successful mail delivery." --Russ Allbery
Andrew Gierth
Matt> Newscene is almost as bad as alt.net ...
Newscene is worse. At least with Altopia you can alias out news.alt.net
and be done with them, though you take some loss from downstream sites
like aa.net.
--
Andrew.
Matt Dillon
:>:In article <712noq$fod$1...@east44.supernews.com>,:> Handing out an IP address that is more then likely a dynamic PPP dialup
:> does not throw away privacy, but it does prevent complaints from getting
:> to where they need to go. It isn't YOU that we are interested in...
Just call me Mr. word trip.
Handing out an IP address that is more then likely a dynamic PPP dialup
does not throw away privacy, but it DOES allow commplaints to get to
where they need to go.
-Matt
Afterburner
>Either way, there is no violation of privacy. Arguments claiming
>otherwise have no merit.
For suitable values of "privacy" and "merit", respectively.
Yours,
Afterburner
Matt Dillon
No, the correct source is the spammer's ISP. The USENET provider is
like a long distance phone company... it's trivial to change providers,
and shutting down the USENET provider doesn't kick any sense into the
spammer. I would CC the USENET provider, but my email would be to the
dialup ISP. If a product were being advertised, my email would be to
the ISP hosting the advertisement destination (if on the net, most are
1-800 numbers these days), second the ISP, and last the USENET provider.
Matt Dillon
:Andrew Gierth <and...@erlenstar.demon.co.uk> wrote:
EMail their downstream sites telling them that their upstream site
is getting filtered out :-). That's what I usually do. When
downstream users realize their postings aren't getting to the USENET
at large, they complain to their ISPs which complain to their upstream
'pay' site which pressures the upstream site to clean up their mess.
Matt Dillon
:Afterburner <abu...@erols.com> wrote:
What it comes down to is this: All USENET sites depend on relatively
free transit to operate. When some sites start to operate pay-for-news
NNTP services *AND* abuse their neighbors at the same time, for profit,
I don't see why those of us providing backbone transit should continue
to do so for those sites.
'privacy' and 'merit' are what the upstream operators say it is. Many
of us already consider the way these sites operate to be abusive...
giganews isn't quite there yet, but alt.net, newscene.com, newsguy.com,
usit.net, and others have already crossed the line. I don't transit any
of them any more.
I don't think it would take much of a campaign to convince most of the
backbone to drop them. The damage is simply becoming too severe. When
these services start to remove critical headers (nntp-posting-host and
X-Trace) to, theoretically, 'protect' their userbase's privacy, they make
it even more difficult for their upstream sites to justify the transit.
If the commercial news services don't clean up their act soon, this sort
of backlash is bound to happen. It's trivial to locate someone's upstream
provider(s). Stick to it and you get the backups, too. After a while,
as the number of paths goes down, the backups (which aren't expecting the
jump in bandwidth) start shutting off the feeds on their own.
Andreas Barth
> And I think Fluffy already has a semi-working implementation of cancel
> locks; you may want to take a look at that before you get started.
That means at http://members.tripod.com/~gerglery/
There is a implementation for inn to work with canlocks and an
implementation of canlock for slrn and tin. I've installed it here and it
works fine.
Andi
--
Andreas Barth <a...@muenchen.pro-bahn.org> PGP-Key auf Anforderung
======PGP-Fingerabdruck DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C======
Aber die Halbwertszeit der Planungen der Stadtwerke werden wohl
auch immer kuerzer ... Lucas Neubauer
Andreas Barth
> The above header idea is integrated with the other two and covers the
> *entire* news system infrastructure. Not just a tiny piece of it.
> (and, in fact, I don't even need to distribute the private key there,
> I can just sign that one header with the private key).
>
> *BIG* difference.
Yes, makes it easy to mess up things. I like the unix way more:
Do one thing and do it good.
Canlock *is* coded right now and works here.
NoCeM *is* coded and works fine. There are problems, but these could be
solved. (And it's more easier to solve these problems than to invent
something new with the same problems.)
pgpverify *is* coded and works for a long time now.
Did I understand your proposal right that you want an individual
signing-key for each posting that should be posted when canceling?
Afterburner
> What it comes down to is this: All USENET sites depend on relatively
> free transit to operate. When some sites start to operate pay-for-news
> NNTP services *AND* abuse their neighbors at the same time, for profit,
> I don't see why those of us providing backbone transit should continue
> to do so for those sites.
<snip>
> If the commercial news services don't clean up their act soon, this sort
> of backlash is bound to happen. It's trivial to locate someone's upstream
> provider(s). Stick to it and you get the backups, too. After a while,
> as the number of paths goes down, the backups (which aren't expecting the
> jump in bandwidth) start shutting off the feeds on their own.
Great. But what does this have to do with Erol's/RCN? We're not a
commercial news service. We're an ISP (several ISPs, actually). If you
see "X-Complaints-To: ab...@rcn.com" in a news post, one of two things will
be true:
(A) The article was posted by an RCN customer.
(B) The article wasn't posted by an RCN customer, and instead has
forged headers inserted in order to throw off the trail.
If abuse is committed and (A) is involved, you have no problems
because I and my Minions can, and will, LART abusive users.
If abuse is committed and (B) is the case, you're no worse off than
you would be if the X-Trace: were unencrypted. In fact, provided I have
the full headers, one could argue that you're better off. Consider:
* If the abuser completely fabricates one or both of the X-Trace:
and/or Message-ID: headers, I will quickly discover that it's a bogus post
for obvious reasons.
* If the abuser copies an existing X-Trace/Message-ID pair into his
forged headers, it either won't propogate (or propogate poorly) due to
there being a duplicate Message-ID already on Usenet, or the date of
posting will be at substantial variance with the date returned by the
encrypted X-Trace. Either one is yet again a clue that the header info is
bogus.
At least, that's my understanding of things. My understanding may,
of course, be flawed in one or more respects.
Yours,
Afterburner
Matt Dillon
:Andreas Barth <a...@muenchen.pro-bahn.org> wrote:
:>On 26 Oct 1998 10:51:52 -0800, Matt Dillon <dil...@best.net> wrote:
:>
:>Did I understand your proposal right that you want an individual
:>signing-key for each posting that should be posted when canceling?
Yes. It doesn't have to be strong encryption though... the key doesn't
really have to be any larger then a signature. Don't make the mistake
of assuming that because people throw 1024 bit keys around, that you
HAVE to throw 1024 bit keys around. For something with only cancel
or supersedes authority, a 200 bit key would work just fine.
-Matt
:>Andi
:>--
:> Andreas Barth <a...@muenchen.pro-bahn.org> PGP-Key auf Anforderung
Matt Dillon
:Andreas Barth <a...@muenchen.pro-bahn.org> wrote:
:>On 26 Oct 1998 10:51:52 -0800, Matt Dillon <dil...@best.net> wrote:
:>
:>> *entire* news system infrastructure. Not just a tiny piece of it.
:>> (and, in fact, I don't even need to distribute the private key there,
:>> I can just sign that one header with the private key).
:>>
:>> *BIG* difference.
:>
:>Yes, makes it easy to mess up things. I like the unix way more:
:>Do one thing and do it good.
:>
:>Canlock *is* coded right now and works here.
:>
:>NoCeM *is* coded and works fine. There are problems, but these could be
:>solved. (And it's more easier to solve these problems than to invent
:>something new with the same problems.)
:>
:>pgpverify *is* coded and works for a long time now.
:>
:>Did I understand your proposal right that you want an individual
:>signing-key for each posting that should be posted when canceling?
:>
:>
:>Andi
PGP is a mess, Cancel-Lock is so narrowly defined as to be utterly
useless, and NoCem isn't really a standardized replacement for
cancels. It works. But even all three together don't even come close
to fixing the issues that have come up in the last few years... you'd
have to tack on another three or four mechanisms on top of the mess
you already have.
The scheme I described implements a *single* mechanism that effectively
covers a broad range of news-related control applications, including
all control, cancel, and supersedes handling. From a coding standpoint,
one needs to get just this one feature right rather then have to get
each of a half dozen little independantly written subsystems right.
It is far easier to develop a more general protocol that you need only
debug once then to develop half a dozen protocols that are narrowly
defined.
-Matt
Matt Dillon
:Afterburner <abu...@erols.com> wrote:
:>dil...@best.net (Matt Dillon) sez:
:>
:>> What it comes down to is this: All USENET sites depend on relatively
:>
:> Great. But what does this have to do with Erol's/RCN? We're not a
:>commercial news service. We're an ISP (several ISPs, actually). If you
:>see "X-Complaints-To: ab...@rcn.com" in a news post, one of two things will
:>be true:
Well, you mean apart from cryping your X-Trace: headers? Nothing.
But by crypting X-Trace and getting rid of NNTP-Posting-Host, you are
not being a good net neighbor.
All that you accomplish by crypting X-Trace is, if you are not running
your own rate filters, preventing other news systems from running *their*
own correlating rate filters to deal with the situation when one of your
users decides to spam. You are adding significant overhead to your own
abuse department as well.
Why? At the very least, keep the posting IP address in there so other
people's rate filters will work. Why purposefully fuckup other news
systems? You know how spammers operate: The expect to get kicked off.
If you purposefully remove headers that cancelbots and system rate filters
use to detect mass postings, you hurt everyone.
-Matt
:> Yours,
:> Afterburner