Re: RemailerNet

In message <199408051528.LAA18523@cs.oberlin.edu> Jonathan Rochkind writes:

> You seem to be talking about a Julf-style anon system, where the system
> knows who you really are. If the system is corrupt, if Julf were an 
> NSA agent, then the entire system is compromised and useless.

If you are using unmodified Internet hardware and TCP/IP as the underlying
transport system, then your point of entry into a remailer network
definitely knows which machine is originating a message and the point
of exit definitely knows where it is going.

If your transport system is the email system, the same holds true because
email runs on top of TCP/IP.  While fiddling with email headers may make
you feel secure, it gives you no protection.

It is a large project (say 30,000 lines of code, some of it at the kernel
level) to build a remailer network which does not use SMTP and TCP/IP.
From the scale of efforts that you are talking about, I assume that you do
not intend to do this.

So the remailer gateways know the source and destination addresses, they
know your electronic identity.	This may or may not lead them to your
physical identity.  That can be concealed fairly easily, especially in
large institutions with poor control over their network resources.  But
this has nothing to do with our discussion now.

> I like the cypherpunks remailer concept better, where each link in the chain
> only knows the next link in the chain, and security is achieved by
> multiple links. If several of the links are actually NSA agents, your security
> is reduced, but not compromised completely. If you've got a chain of, say
> 10 links, even if 7 of them are evil NSA agents, you still can probably retain
> your anonymity.  Return addresses are accomplished by encrypted
> "resend-to:" blocks. It seems much preferable to have a system where it
> isn't neccesary to trust any one net entity completely, as it is in a 
> Julf-style anon-ID system. [Of course one could use a combination of both
> in communications too, but I wouldn't feel safe unless my anonimity was
> safe even if the Finish FBI raided Julf's site.]

Promiscuity leads to infection.  Each contact with a new RemailerNet
gateway increases the probability of your being compromised.

If you modify the proposed RemailerNet to allow reposting at gateways,
you have all of the benefits of the system described above, without
the risks.  Reposted messages would be encrypted with the far gateway's
public key.  The near gateway would then have no idea of the ultimate
destination of the message.  In a well designed system, the far
gateway would also not know the identity of the sender.

> When looked at with this goal in mind, I think maybe the newsgroup as a method
> of passing remailer net information makes a bit more sense. 
>  
> I don't think the possibility of the newsgroup being spoofed is actually
> fatal to the system. Let's examine ways in which it could be attacked:
> 
> 1)  The Enemy could introduce completely made-up "i'm here" messages, pointing
> to non-existent remailers. ...
> 2) The Enemy could announce his own Evil-remailers to the net. These remailers
> would in fact exist, but would do evil things designed to compromise the net...
> 3) The Enemy could intercept announcement messages from good remailers, and
> replace their public key with his own. ...He could then intercept all mail to this
> good remailer, and read it, and forward it on, or drop it in the bitbucket.
> 4) Denial of service: The enemy could intercept the announcement messages, and
> keep them from getting to the newsgroup. ...
> 5) The enemy could intercept announcement messages from good remailers, and
> replace both the public key and address with his own. This is really just a
> combination of several of the previous attacks, nothing new.

In the early to mid 1950s the FBI set out to penetrate Communist Party
USA cells.  At some point, when the fear of the Red Menace began to recede,
people began to talk.  The communists said, "you could always tell who
were the FBI agents.  They were the ones who paid their dues."  The FBI
was actually providing most of the funds for CPUSA.

If anyone cared enough, what they would do is (a) put up enough remailers
so that they were, say, a steady 80% of those announcing in the alt.x
group; (b) provide a good, reliable service nearly all of the time; and
(c) drive the other 20% out of business with a steady disinformation
campaign (rumors, complaints, etc) and other more aggressive tactics.
The FBI types running (a) and (b) would be well funded and they would
be the sort of steady, unimaginative people who run small businesses
well.  The CIA field agents masterminding (c) would be very well
funded network freaks, some of them ex-hackers.  They could operate
outside the USA and pay little or no attention to US laws.  Pity the
poor 20% in the face of such attacks.

Any traffic sent through this remailer network would have only a tiny
chance of getting through without being compromised.  If you picked
5 remailers, the chances of all being non-FBI would be about .2^5,
3 in 10,000.  The other 9,997 messages would be copied immediately
to Langley.

The proposed RemailerNet could be attacked in much the same way.  But
if the network were widely distributed so that gateways were in
different legal jurisdictions and different countries, and if most of
the people involved knew one another, it would be more difficult to
compromise it.
--
Jim Dixon

Jim Dixon:

| In message <199408051528.LAA18523@cs.oberlin.edu> Jonathan Rochkind writes:

| > You seem to be talking about a Julf-style anon system, where the system
| > knows who you really are. If the system is corrupt, if Julf were an 
| > NSA agent, then the entire system is compromised and useless.
| 
| If you are using unmodified Internet hardware and TCP/IP as the underlying
| transport system, then your point of entry into a remailer network
| definitely knows which machine is originating a message and the point
| of exit definitely knows where it is going.

	IP is not reliable & trustworthy.  It it was, RFC931 ident
servers would be useful. ;)  Theres source routing to make packets
appear to come from someplace else, and there is outright forgery,
which has limits, but can work quite well.

	For a good discussion of some of TCP/IP's reliability &
trustworthyness, see Steve Bellovin's paper,
research.att.com:/dist/internet_security/ipext.ps.Z

	An aside: Does anyone care to share thoughts on IPng's
security features?


Adam

-- 
Adam Shostack 				       adam@bwh.harvard.edu

Politics.  From the greek "poly," meaning many, and ticks, a small,
annoying bloodsucker.

Adam Shostack says:
> An aside: Does anyone care to share thoughts on IPng's security
> features?

I'm the person assigned to edit/write the drafts for IPSP, which is to
be the successor to swIPe, and portions of which will be mandatory
parts of conformant IPv6 security. (Now that the decision on which
protocol is to be IPng, the politically correct name for IPng is
"IPv6").

The basic technique of packet encapsulation for security, which is the
basis for SP3, NLSP and swIPe, is being adopted, although the packet
format is being radically simplified even from that of swIPe,
consisting mainly of an SAID (what swIPe calls a "Policy Identifier).
Authentication and opaque cryptographic encapsulation formats are to
be slightly different for technical reasons.

The IPSP definition is (nearly) nailed down. The hard part, key
management, which is the layer that goes on top of IPSP, is still
being intensively discussed. I expect there will be extensive battles
there still to come, particularly on the naming of authenticated
entities -- to tell you how shaky things are there, no real proposals
are yet in draft RFC form. The one thing there is widespread agreement
on is that the DNS should be used to store keys, although this will
likely require extension of the maximum size currently permitted for
RRs in the DNS (512 bytes as defined right now.)

It is my hope that a unified IKMP (internet key management protocol)
and IPSP will provide sufficient functionality that no other security
mechanisms will be required for authenticating and securing remote
connections on the internet, and any telnet, ftp, finger, or anything
else that anyone does can be transparently made secure simply by
setting administrative requirements on the authentication and
encryption level needed by connections. Security of store-and-forward
traffic, like electronic mail and routing information, will still
require seperate mechanisms -- I hope the basic keys for those
mechanisms will be stored in the same way with the same naming, for
instance, and that most of the mechanisms will be shared.

It is also my hope that all trust mechanisms will be based on
web-of-trust rather than certification heirarchies, although that is
another speculation.

Perry