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
participants (3)
-
Adam Shostack -
jdd@aiki.demon.co.uk -
Perry E. Metzger