[cancels] $alz convention changes
Andrew Gierth
actually) to modify the convention used for message-ids of spam
cancels. While the method of preempting the $alz cancel has been used
on relatively rare occasions in the past, usually for isolated
spamming or flooding incidents, the method is currently being used in
conjunction with large-scale ordinary spamming.
Accordingly, myself and several of the other significant despammers
have modified our procedures as follows: instead of using just
<cancel. for the prefix, we now use <cancel.XXXX. where XXXX is a
16-bit number expressed in hex. The procedure for calculating this is
deterministic (all of us will use the same value for any given cancel)
but is not predictable (we hope) by anyone not knowing the algorithm
and shared secret, which will be distributed on a need-to-know basis.
The initial "<cancel." was deliberately kept because of the existence
of configuration options causing such IDs to be refused on the
assumption that they are spam-cancels. Sites that are using INN's
message-id filter to refuse cancels for already-rejected articles will
need to make appropriate changes to their code.
This does, however, break the approach of adding the $alz message-id
to history when rejecting an article. That unfortunately can't be
helped; it's exactly this predictability of the cancel message-id
which needs to be avoided.
--
Andrew.
"I believe we've been over this before. There isn't need for any sort
of security feature unless some asshole wants to make a nuisance of
himself." Matt (ARPAVAX:glickman) in net.rumor, Dec 1981
Rosalind Hengeveld
explanation of the $alz convention in its classical version.)
Andrew Gierth <and...@erlenstar.demon.co.uk> in
<87n0w1p...@erlenstar.demon.co.uk>:
> It's finally become necessary (several years later than expected,
> actually) [...]
>
> Accordingly, myself and several of the other significant despammers
> have modified our procedures as follows: instead of using just
> <cancel. for the prefix, we now use <cancel.XXXX. where XXXX is a
> 16-bit number expressed in hex. The procedure for calculating this is
> deterministic (all of us will use the same value for any given cancel)
> but is not predictable (we hope) by anyone not knowing the algorithm
> and shared secret, which will be distributed on a need-to-know basis.
Ingenious, sure. But I wonder whether this kind of $alz has not all but
outlived its usefulness.
All it is good for is to save a tiny amount of bandwidth and disk space
by preventing several cancels by 'significant despammers' from
coexisting. As against that, the $alz in its old or new version makes
it possible for one malformed cancel -- whether intentional or not -- to
preempt other, well-formed cancels for the same article.
Since the mid-1990s, when Usenet spamming began to be a problem and the
protocols such as the third-party cancel (with the $alz convention) and
NoCeM were -- not without success, fortunately! -- introduced as
counter-measures, resources such as bandwidth and disk space have become
orders of magnitude less of an issue than they were back then.
On the other hand, the use of Usenet, while grown, seems not to have
kept pace with the capacity of resources, not even with the growth of
other uses of the internet like e-mail and the web.
The reasons are open to dispute, of course, but may well lie in forms of
abuse such as spam (and others), which 'turn people away' from Usenet.
Therefore, as a general policy, I would suggest that combating Usenet
abuse -- while satisfying time-honored 'metacriteria' such as that
deletion criteria be objective and content-neutral -- should have
piority over saving moderate amounts of resources in doing so.
Also, while in the 1990s the emphasis was om combating abuse which made
a disproportionate use of resources, the trend seems now to combat abuse
because it limits the very usability of Usenet. Of course, spam
(excessive multi-posting) does both evils, but this shift in emphasis
does have consequences for spam *fighting*.
In the nl.* (Netherlands) hierarchy, pure excessive cross-posting has
become eligible for deletion lately (based on HI>30, maximum five groups
without adequate follow-up). This would seem an example of combating a
form of abuse which does not make disproportionate use of resources, but
which does threaten the usability and viability of Usenet.
I should also like to point out that the NoCeM protocol does not provide
any provision which would prevent one and the same article from being
targeted by several NoCeMs. Few people worry about it.
As for another point: a 'shared secret, which will be distributed on a
need-to-know basis' expressed in sixteen bits will not stay secret for
long. In a time when even 512-bit PGP is no longer guaranteed safe,
cracking it will only be a matter of not too much time. The ones to
crack (and likely publish) it will probably not be the spammers -- whose
stupidity is never to be underestimated, witness the above 'several
years later than expected' -- but smart, non-spamming whizz-kids who
just don't like being left out of a secret.
All this would plead, I think, either for total abandonment of the $alz,
or for -- because of other uses of the 'cancel.' prefix -- a form like
'<cancel.XXXX.' where XXXX is totally *random* (so, different between
any two cancels) and thus never open to preemption.
Am I missing anything? Thoughts would be appreciated.
Chris Lewis
> As for another point: a 'shared secret, which will be distributed on a
> need-to-know basis' expressed in sixteen bits will not stay secret for
> long. In a time when even 512-bit PGP is no longer guaranteed safe,
> cracking it will only be a matter of not too much time.
Do note that the key isn't necessarily 16 bits, nor is the rest of the
bits and pieces that factor into the encryption.
So, no, it's a lot more than 16 bits to crack.
--
Chris Lewis,
For more information on spam, see http://spam.abuse.net/spam
It's not just anyone who gets a Starship Cruiser class named after them.
Graham Drabble
news:87n0w1p...@erlenstar.demon.co.uk:
> Accordingly, myself and several of the other significant
> despammers have modified our procedures as follows: instead of
> using just <cancel. for the prefix, we now use <cancel.XXXX. where
> XXXX is a 16-bit number expressed in hex. The procedure for
> calculating this is deterministic (all of us will use the same
> value for any given cancel) but is not predictable (we hope) by
> anyone not knowing the algorithm and shared secret, which will be
> distributed on a need-to-know basis.
Is there any consensus on what moderators should do about this? When
cancelling forge approvals I have always tried to follow the $alz
convention so that if it is also hit by despammers there isn't
duplicates. I guess that you don't want to make the algorithm known to
all so has anyone any suggestions? My first thought is that, as there
aren't many cancels in that category, that overlap probably isn't a
problem but I was wondering what others fealt.
--
Graham Drabble
If you're interested in what goes on in other groups or want to find
an interesting group to read then check news.groups.reviews for what
others have to say or contribute a review for others to read.
Andrew Gierth
Rosalind> Ingenious, sure. But I wonder whether this kind of $alz
Rosalind> has not all but outlived its usefulness.
Rosalind> All it is good for is to save a tiny amount of bandwidth
Rosalind> and disk space by preventing several cancels by
Rosalind> 'significant despammers' from coexisting.
The difference between 100k cancels/day and 200-300k cancels/day is
significant enough to be worth the (very minor) effort.
Most importantly, there's still an upper bound on the number of
cancels in relation to the amount of spam.
On the other hand, I don't expect this method to be needed (or used)
by smaller-scale cancellers. A few thousand $alz-cancels in addition
to the new-format ones will not present any significant problems.
Rosalind> Since the mid-1990s, when Usenet spamming began to be a
Rosalind> problem and the protocols such as the third-party cancel
Rosalind> (with the $alz convention) and NoCeM were -- not without
Rosalind> success, fortunately! -- introduced as counter-measures,
Rosalind> resources such as bandwidth and disk space have become
Rosalind> orders of magnitude less of an issue than they were back
Rosalind> then.
Bandwidth and disk space perhaps. But history file size and number of
lookups are still issues, and inflating the total number of messages
in transit unnecessarily is still a bad idea.
Rosalind> I should also like to point out that the NoCeM protocol
Rosalind> does not provide any provision which would prevent one and
Rosalind> the same article from being targeted by several NoCeMs.
Rosalind> Few people worry about it.
It would, however, be more of an issue if there were more high-volume
nocem issuers.
Rosalind> As for another point: a 'shared secret, which will be
Rosalind> distributed on a need-to-know basis' expressed in sixteen
Rosalind> bits will not stay secret for long.
The secret is longer than that (and in fact can be made as long as
needed).
Andrew Gierth
Graham> Is there any consensus on what moderators should do about
Graham> this?
I personally would not advise moderators to follow $alz (even before
these latest changes). Chris's original "artcancel" script used
"<can.".random(32767). as the prefix for cancels for forged-approvals,
and that's as good an approach as any.
Graham> When cancelling forge approvals I have always tried to follow
Graham> the $alz convention so that if it is also hit by despammers
Graham> there isn't duplicates.
This is only worth worrying about if you're dealing with sustained
floods of thousands+ per day.
Chris Lewis
> >>>>> "Graham" == Graham Drabble <graham....@lineone.net> writes:
>
> Graham> Is there any consensus on what moderators should do about
> Graham> this?
> I personally would not advise moderators to follow $alz (even before
> these latest changes). Chris's original "artcancel" script used
> "<can.".random(32767). as the prefix for cancels for forged-approvals,
> and that's as good an approach as any.
I do not recommend following $alz either. Moderator cancels are entirely
outside of the arena of spam cancels, and so aren't optional (to the
site owner) at all.
Rosalind Hengeveld
> > As for another point: a 'shared secret, which will be distributed on a
> > need-to-know basis' expressed in sixteen bits will not stay secret for
> > long. In a time when even 512-bit PGP is no longer guaranteed safe,
> > cracking it will only be a matter of not too much time.
Chris Lewis <cle...@pte.nortelnetworks.com> in
<a9vf2j$pd8$1...@bcarh8ab.ca.nortel.com>:
> Do note that the key isn't necessarily 16 bits, nor is the rest of the
> bits and pieces that factor into the encryption.
>
> So, no, it's a lot more than 16 bits to crack.
Point taken. Yes, I confused the length of the encrypted *result* (16
bits) with the length of the encryption *key* (possibly much longer).
--
Rosalind Hengeveld
Rosalind Hengeveld
> > I personally would not advise moderators to follow $alz (even before
> > these latest changes). [...]
Chris Lewis <cle...@pte.nortelnetworks.com> in
<a9vs81$gdu$1...@bcarh8ab.ca.nortel.com>:
> I do not recommend following $alz either. Moderator cancels are entirely
> outside of the arena of spam cancels, and so aren't optional (to the
> site owner) at all.
Another point taken. I should like to point out, however, that -- until
recently at least -- any third-party cancel lacking the $alz used to be
labeled as 'malformed', and moderator cancels were usually not clearly
stated as exceptions.
If moderator cancels aren't optional (to the site owner) at all, does
that mean they don't have to follow the !cyberspam pseudosite convention
either? In other words: do they not really count as third-party
cancels? An X-Canceled-By header would still seem to make sense.
--
Rosalind Hengeveld
Graham Drabble
news:3cc44d02$0$37927$e4fe...@dreader3.news.xs4all.nl:
> Chris Lewis <cle...@pte.nortelnetworks.com> in
> <a9vs81$gdu$1...@bcarh8ab.ca.nortel.com>:
>
>> I do not recommend following $alz either. Moderator cancels are
>> entirely outside of the arena of spam cancels, and so aren't
>> optional (to the site owner) at all.
>
> Another point taken. I should like to point out, however, that --
> until recently at least -- any third-party cancel lacking the $alz
> used to be labeled as 'malformed', and moderator cancels were
> usually not clearly stated as exceptions.
I always thought that this part was mandatory to prevent collisions.
> If moderator cancels aren't optional (to the site owner) at all,
> does that mean they don't have to follow the !cyberspam pseudosite
> convention either?
However I've never bothered with these. A) I'm injecting with POST so
don't the what result I'd get and B) it isn't always spam that is being
cancelled.
> In other words: do they not really count as
> third-party cancels? An X-Canceled-By header would still seem to
> make sense.
I think I use that and the Sender header.
Andrew Gierth
Rosalind> Another point taken. I should like to point out, however,
Rosalind> that -- until recently at least -- any third-party cancel
Rosalind> lacking the $alz used to be labeled as 'malformed',
by whom? not in my reports - they tend to show up as "suspicious" if I
haven't added the specific moderator as a special case, or if the
moderator has moved or changed the style of their cancels since I last
updated my list.
There are _no_ required conventions for moderator cancels, originating
site (TOS etc.) cancels, forgery cancels or author cancels. This means
I can't identify them except on an ad-hoc basis, so they tend to show
up in the catch-all "suspicious" category.
Rosalind> If moderator cancels aren't optional (to the site owner) at
Rosalind> all, does that mean they don't have to follow the
Rosalind> !cyberspam pseudosite convention either? In other words:
Rosalind> do they not really count as third-party cancels?
Correct; they do not really count as third-party cancels.
Rosalind> An X-Canceled-By header would still seem to make sense.
even that's optional.
Andrew Gierth
[$alz for moderators]
Graham> I always thought that this part was mandatory to prevent
Graham> collisions.
nope. For moderator cancels that's not an issue (unless you're dealing
with multi-thousand-post floods which are also being handled by one of
the despammers). If it ends up that there are some duplicate cancels
then that's no big deal as long as they don't become a volume problem
in themselves.
Dave Korn
news:a9vf2j$pd8$1...@bcarh8ab.ca.nortel.com...
> According to Rosalind Hengeveld <rosa...@xs4all.nl>:
> > As for another point: a 'shared secret, which will be distributed on a
> > need-to-know basis' expressed in sixteen bits will not stay secret for
> > long. In a time when even 512-bit PGP is no longer guaranteed safe,
> > cracking it will only be a matter of not too much time.
>
> Do note that the key isn't necessarily 16 bits, nor is the rest of the
> bits and pieces that factor into the encryption.
>
> So, no, it's a lot more than 16 bits to crack.
Although the secret may be more than 16 bits, there's only 16 bits worth
of information coming out of the algorithm and going into the msgid.
So the question is: how many pre-emptive <cancel.NNNNN.msgid> (with random
NNNNN) would a spammer have to issue alongside each spam with <msgid> before
the birthday paradox would guarantee a reasonable chance of success?
Hmm, I suppose I should go google the maths of it myself, but I just
thought I'd point out the possibility: it would be an *awful* lot less than
32768 of them in order to get >50% chance of successfully pre-empting the
cancel under the new convention. Is there any serious reason not to use
32-bit or larger prefixes?
DaveK
--
moderator of
alt.talk.rec.soc.biz.news.comp.humanities.meow.misc.moderated.meow
Burn your ID card! http://www.optional-identity.org.uk/
Help support the campaign, copy this into your .sig!
Proud Member of the Exclusive "I have been plonked by Davee because he
thinks I'm interesting" List Member #<insert number here>
Master of Many Meowing Minions
Holder of the exhalted PF Chang's Crab Wonton Award for kook spankage above
and beyond the call of hilarity.
Andrew Gierth
Dave> Although the secret may be more than 16 bits, there's only 16
Dave> bits worth of information coming out of the algorithm and going
Dave> into the msgid.
Dave> So the question is: how many pre-emptive <cancel.NNNNN.msgid>
Dave> (with random NNNNN) would a spammer have to issue alongside
Dave> each spam with <msgid> before the birthday paradox would
Dave> guarantee a reasonable chance of success?
The birthday paradox doesn't apply. The attacker is trying to hit a
fixed (but unknown to him and apparently random) target, not merely
trying to find a collision between _any_ two items in a set. This
makes the difficulty O(N) rather than O(sqrt(N)).
Dave> Hmm, I suppose I should go google the maths of it myself, but
Dave> I just thought I'd point out the possibility: it would be an
Dave> *awful* lot less than 32768 of them in order to get >50% chance
Dave> of successfully pre-empting the cancel under the new
Dave> convention.
your maths is wrong - if the spammer issues 32768 different preemptive
cancels then they have exactly a 50% chance of success.
Chris Lewis
> <a9vs81$gdu$1...@bcarh8ab.ca.nortel.com>:
>
> > I do not recommend following $alz either. Moderator cancels are entirely
> > outside of the arena of spam cancels, and so aren't optional (to the
> > site owner) at all.
> Another point taken. I should like to point out, however, that -- until
> recently at least -- any third-party cancel lacking the $alz used to be
> labeled as 'malformed', and moderator cancels were usually not clearly
> stated as exceptions.
I'll repeat Andrew's "by whom"? Technically, the only thing that matters is
the minimal cancel security contained in certain news implementations. This
has nothing to do with paths or message-ids.
> If moderator cancels aren't optional (to the site owner) at all, does
> that mean they don't have to follow the !cyberspam pseudosite convention
> either? In other words: do they not really count as third-party
> cancels? An X-Canceled-By header would still seem to make sense.
They're second-party cancels. !cyberspam doesn't apply either, and I would
discourage any suggestion that any mandatory pathtail (resulting in it
being aliasable) was necessary or even encouraged.
X-Canceled-by is a good idea, simply for courtesy's sake, so that anyone trying
to investigate one doesn't have to go down too many ratholes.
Ie: X-Canceled-by: "Moderator of group X" <emailaddr>
Reverend Wednesday
in <8kj6cugkems6sl0nh...@4ax.com>,
IRS Agent <ta...@yourwallet.empty.gov> rightfully proclaimed:
>
>I've been cutting youse guys a lot of slack for three years and
>haven't been designing swiss army knives in that time. ;)
>
>There are many vulnerabilities remaining. Please choose wisely
>while oppressing the usenet masses. Every now and then they get
>pissed off something fierce and revolt in unpredictable ways when
>you get too heavy-handed.
>
Cabalistas like Andrew, Chris, or other "significant despammers"
think nothing of oppressing the usenet masses and could not care
less how pissed off any of us get.
Notice how they changed a "convention" without even so much as
a discussion. If there's no cabal, then who made the decision
to change the $alz convention?
Sickening. It's no wonder that tools like H-C's N-A exist, and
that people like Jessica Felix make heavy use of them.
If you know of other vulnerabilities, please post the details here,
then the weapon-smithies like all those H-clones can get busy and
spamZspamWONDERFULLspam. After all, wasn't it the latest release
of Mr.H.C's that caused the censors to change their "conventions"?
Something about pre-emptive cancels? Snicker.
Chris Lewis
> Andrew Gierth wrote:
> > It's finally become necessary (several years later than expected,
> > actually)
Ectually, back in 1995, the Moose, snowhare, and I had
already decided upon a convention for this. Namely,
choose one or more of letters in "cancel." to
capitalize. Nominally "cancel.", then "Cancel",
"cAncel", "CAncel" ... in that sequence. Since there were
so few of us, it was been a trivial thing to talk to each
other to decide which we were going to use on any given day
if the need arose.
That convention was used occasionally over the intervening
years, and was adequate for the most part. But it required
manual intervention.
The new standard is a vast improvement, because it's automatic
and requires no intervention at all.
> There are many vulnerabilities remaining. Please choose wisely
> while oppressing the usenet masses. Every now and then they get
> pissed off something fierce and revolt in unpredictable ways when
> you get too heavy-handed.
How this has anything to do with Message-ID format is totally beyond
me.
Seth Breidbart
Rosalind Hengeveld <rosa...@xs4all.nl> wrote:
>As for another point: a 'shared secret, which will be distributed on a
>need-to-know basis' expressed in sixteen bits will not stay secret for
>long. In a time when even 512-bit PGP is no longer guaranteed safe,
>cracking it will only be a matter of not too much time. The ones to
>crack (and likely publish) it will probably not be the spammers -- whose
>stupidity is never to be underestimated, witness the above 'several
>years later than expected' -- but smart, non-spamming whizz-kids who
>just don't like being left out of a secret.
The secret itself can be longer.
Note: I don't know it.
If I were implementing a system like that, I'd say that the shared
secret is: (1) Take this file of 350 bytes <some random stuff>, (2)
append the Message-ID of the message being cancelled, including the
<>, (3) computer the MD5 hash of the resulting 370 or so bytes, and
(4) take the 16 bits in even positions 10-40.
How long do you think it would take you to crack that little trick?
Seth
Peter da Silva
Bloxy's <bloxy's...@resistance-to-totalitarianfascists.ua> wrote:
>The newsgroups are controlled on all levels by the extensive
>network of various groups including the newsnet power
>elite, the news admins, Cabal/SPUTUM (Subgenious Police
>Usenet Tactical Unit (Mobile)) http://www.sputum.com and
>various other "heroes", "spam fighters" and all sorts of
>megalomaniacs.
Funny, I thought they were controlled by the porn spammers, software
pirates, and other rip-off artists. The tiny remnant of actual discussion
makes up such a small part of the total volume I'm surprised anyone
cares who's got any kind of control of *that* any more. They are
insignificant in the grand scheme of things next to alt.warez.mpeg.movies
or whatever it is this week.
--
Rev. Peter da Silva, ULC. WWFD?
"Be conservative in what you generate, and liberal in what you accept"
-- Matthew 10:16 (l.trans)
Peter da Silva
Bloxy's <bloxy's...@resistance-to-totalitarian-fascists.ua> wrote:
>Go look up your dictionary at least.
Goodness gracious. Do you think you could look up something in there for me.
The entry I have in mind is "nonsequiter".
Thanks ever so much.
*hugs*
Seth Breidbart
><aad6dd$9sm$1...@panix3.panix.com>:
>
>> The secret itself can be longer.
>
I'm someone who has done a little research in cryptography.
You're nobody.
>Violent bastardazoid, branwashing young people into oblivion,
>telling where ideas belong, converting democracy into suckocracy
>and lickassocracy.
You don't even speak English.
>> If I were implementing a system like that, I'd say that the shared
>> secret is: (1) Take this file of 350 bytes <some random stuff>, (2)
>> append the Message-ID of the message being cancelled, including the
>> <>, (3) computer the MD5 hash of the resulting 370 or so bytes, and
>> (4) take the 16 bits in even positions 10-40.
>
>Zo... you have vested interest in supressing all other views
>but your own sucky party line of stupidity and reduction of
>intelligence to the level of a machine.
If you had a brain, you'd understand the concepts I wrote about.
Seth