1994-02-15 - The Difficulty of Source Level Blocking

Header Data

From: tcmay@netcom.com (Timothy C. May)
To: cypherpunks@toad.com
Message Hash: fd731ac2471d8ee76b74ed223b910cae47e95d154089418c4e64b2cefa863ed5
Message ID: <199402151938.LAA13708@mail.netcom.com>
Reply To: <9402151602.AA03825@bogart.Colorado.EDU>
UTC Datetime: 1994-02-15 19:45:39 UTC
Raw Date: Tue, 15 Feb 94 11:45:39 PST

Raw message

From: tcmay@netcom.com (Timothy C. May)
Date: Tue, 15 Feb 94 11:45:39 PST
To: cypherpunks@toad.com
Subject: The Difficulty of Source Level Blocking
In-Reply-To: <9402151602.AA03825@bogart.Colorado.EDU>
Message-ID: <199402151938.LAA13708@mail.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


W. Kinney writes:

> One can only reach the conclusion that Usenet is broken if one assumes
> that the remailers _aren't_. The automatic broadcast property if Usenet
> is not a problem if you can always determine the source of a message. This
> isn't an argument against anonymity, but just saying it's a little
> backwards to say that Usenet has to be redesigned because it doesn't work
> with the remailers.

It's broken in the larger sense that Eric mentioned: costs are not
incurred by posters. This is not just a problem with remailers, but
with the growing numbers of "Make.Money.Fast" and "Allah is Coming!"
sorts of posts. Think about it.

> Why not use technology to solve a technological problem? The difficulty 
> here is that it is impossible for any one remailer operator to prevent 
> someone, say LD, from using the remailer system. The best he can do is stop 
> LD from using his site as an entry point. So why not introduce a little 
> cooperation among operators? This can be accomplished without collusion of 
> the sort that would break anonymity.

Well, this blocking is what Hal is doing, and he proposed that others
do the same, so I don't get your "alternative."

> Pretty much all the remailer operators are 'punks, right? If a critical 
> mass of operators get together and agree to block a standardized set of 
> sources and destinations, then that group of operators will have enough 
> pull to force the other operators to toe the line. The trick is to block 
> messages from remailer _operators_ who refuse to agree to behave as part of 
> the community, effectively isolating the wildcats. An isolated remailer is 
> useless.

Not this easy. To see this, imagine the following scenario:

Alice chooses not to block Detweiler (for example). Bob, Charles,
Dorothy, decide to block Detweiler. Alice receives a message from
Detweiler, strips off the headers in the normal way, passes the
*encrypted* body (remember that many remailers support PGP and that
this is in fact the preferred mode, long term) to Bob, who has
absolutely no idea the body message he sees (encrypted further....) is
a message from Detweiler. Bob does the header stripping and remailing
to Charles, and so on. Eventually, Zeke sends the message on to its
final destination. 

Only at the last stage, in this example, does Zeke realize--if he
bothers to look at the message body, presumably now in plaintext (but
not necessarily)--that the message is a threat, a flame, a "Yahweh is
Coming!" message, or whatever.

Thus, so long as at least *one* remailer is not doing source
screening, and that at least some encryption is used (not all nodes
have to do it, obviously), then source-level screening will not work.

Unless, of course, Alice, Bob, Charles, etc. all agree to "work
backwards" to trace a sender. This dire situation, counter to
everything we want in remailers, would then allow the rest of the
remailers to add _Alice_ to their list of blocked sources. Because she
didn't play ball and didn't block Detweiler. A slow process, and one
that could also be thwarted by, say, Fred, who refuses "on principle"
to keep logs, collude with the other remailers, etc.

No, source-level blocking is a reasonable short term fix for the
present challenge from Detweiler, but is not a long term solution. We
can block Detweiler temporarily, because there are so few remailers,
so little use of chained encryption, etc., but he and others will find
alternatives.

> What we have now is a bunch of single remailers. It's a very small step to 
> create a cooperative group of remailers, and it would provide avenues for 
> solutions to a lot of the potential problems. This is not perfect, but it's 
> better.

I agree here that remailers may organize themselves into
"cooperatives," groups which make common assumpions about what
policies to follow. Thus, in my example, eventually Alice would be
excluded from the group, for not blocking Detweiler in the first
place. But it gets real messy real fast. Does Alice not accept
encrypted messages from "unknown" sources? (For example, it would be
possible for Detweiler to contract with Joe User to have him forward a
single message, then have Sue Foo forward his next message, etc. In
other words, source-blocking fails so long as a remailer accepts
encrypted messages.)

Very long term, when message costs are borne by the sender, this
problem goes away. (Others remain, such as death threats, extortion,
markets for murder, etc., but they're in a different category.)

--Tim May


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power:2**859433 | Public Key: PGP and MailSafe available.




Thread