17 November 1999
Date: 17 Nov 1999 05:20:35 -0000
From: RProcess <rprocess@nym.alias.net>
To: mail2news_nospam@anon.lcs.mit.edu
Subject: Ideas for Future Remailer System
CC: cypherpunks@cyberpass.net
The following is a list of one dozen crude ideas brainstorming 'next generation' remailers. I offer them to whomever is interested in such contemplation, and welcome any comments.
As I described in my post on Selective DoS Attacks, the current remailer system has a number of problem spots which need to be addressed in any long term development plans. That article may be reviewed at
http://www.eff.org/pub/Privacy/Anonymity/1999_09_DoS_remail_vuln.html
1) It is now commonplace for web browsers to use SSL technology to securely connect to web servers for processing orders, exchanging credit card information, etc. This provides the ability to encrypt and verify the data exchange, and to authenticate the server.
Yet current remailers accept and send data only by email. Even if encrypted, the data is vulnerable to loss/destruction, and various forms of traffic analysis en route. Email is also more vulnerable to mail bombing and flooding.
What is needed is a remailer system which enables the client (user) to connect directly to the remailer server using an SSL-like protocol. The server (the remailer) would be authenticated. The user could authenticate if needed (for a 'nym account' authentication, for example). Remailers connecting to other remailers would authenticate one another, and would transfer data securely.
The above would prevent loss, snooping, and corruption of data between users and remailers and between remailers.
It would also allow the potential for a remailer to display a banner in the client when the user connects and sends/retrieves mail, opening up a source of reasonable advertising income.
2) In this format, 'nym-servers' could store and deliver mail directly to users using SSL-like technology, much like the new Hushmail <www.hushmail.com> system does, except that the mail would arrive at the system through a chain, making the user anonymous.
Bandwidth, storage capacity, and processing power (CPU speed) has increased considerably, and will continue to do so. A new remailer system should "think bigger".
The mail between two nym users would nowhere be "email". Much like the Hushmail system, mail destined to non-nym users or to newsgroups would be posted as required.
3) Remailers could distribute public encryption and signing key pairs, with regular expiration dates. These would be used to encrypt chained messages. The encryption keys would be changed periodically, the signing key would be permanent. The SSL-like protocol would use a public session key (perhaps changed hourly, or even per connection if speed allows). The session key could be authenticated using the signing key. The session key would then be destroyed. This provides forward secrecy - even if a remailer is raided or compromised, the key used to encrypt the session is almost immediately unavailable. Thus recording data between remailers with the idea that the key may eventually be available would be ineffective.
4) Clients and remailers would connect directly to remailers to request the current public key (for chaining), or a key-server arrangement could be used. This key would be signed (the signing key is permanent, unless replaced due to compromise).
5) The system should be designed to expect Denial of Service attacks, such as flooding and mail bombing. It should throttle back connections based on how loaded the system is. For example, if the remailer is very busy and a client attempts to send a large message (or group of messages), the connection may be refused ("try again later"). Each IP, and/or each domain, could have a real-time quota, which would automatically vary based on load. The SSL-like connection protocol would make IP spoofing ineffective. Thus mail bombing and spammers would have a very difficult time entering large amounts of data into the system. (All the entry points would be throttled.)
6) The system should expect that some remailers are rogue remailers, deliberately and selectively deleting mail to particular destinations, flooding the system, and attempting to perform traffic analysis.
7) Remailers which only relay data between remailers, and which are isolated from users, should be envisioned. The address of the remailer would be generally unknown, and would not accept general connections, except to other remailers. This creates a somewhat anonymous anonymous remailer. Because people are more likely to run such remailers, this creates the potential for a large core of stable remailers. (If combined with a Napster-like system (see below), all users could act as real-time middle remailers when they are online.)
8) Anonymity is a desirable feature for many kinds of data, not merely email. A new system should be designed to grow beyond the email paradigm, and consider anonymous network proxying in general, including live chatting and messaging (IRC, ICQ, etc. type systems), HTTP, FTP, NNTP, etc. As bandwidth becomes more available this becomes more feasible, and built-in throttling techniques, as opposed to ad hoc remedies, should make such features manageable.
9) An examination of technologies which allow users to share data with users, where the server merely facilitates the connection, should be made. Examples include DCC exchanges initiated from IRC, and the new Napster <www.napster.com> and CuteMX <www.globalscape.com> MP3 exchange systems (these use interesting new paradigms in data networking that have the RIAA in quite a scramble <http://www.mp3.com/news/421.html>. These ideas could be employed in a variety of ways to implement a massive, distributed, file and data sharing capability for anonymous users and providers.
10) Similarly, the problem of a limited number of mail2news gateways could be remedied by everyone on the system (or everyone who chooses to do so) acting as an exit point for various anonymous data. This kind of system becomes powerful as more users participate. Like Napster, only those exit points currently online would be used. Like IRC, various servers would merge available exit points, making sure the system is not dependent on one central server.
11) One avenue of consideration is to make data widely available, but well encrypted, much like alt.anonymous.messages. In this way user systems could be used to propagate data, or an analogy to NNTP servers could be used to allow each remailer to receive ALL messages, and process only those it recognizes as belonging to it. This would help promote successful message propagation, and would provide interesting cover-traffic capabilities.
12) Ultimately, the most desirable anonymous system would be one which operates in real-time, providing the user with an IP address, perhaps integrated in the existing TCP/IP stack for transparency, or via a specially designed client. The user may send (and if desirable receive) data through the remote IP address. The encrypted data is sent through a chain of (automatic or user-selected) anonymizing proxies, which may use multiple paths for redundancy and cover traffic. Throttled dummy traffic, from idle clients also, could be included. Thus the user is given an anonymous virtual ISP account. The account could also include a latency-based email account, etc., for circumstances where a real-time connection would not provide ample anonymity. Anonymous web hosting, FTP, etc, could also be included in such virtual accounts. Once the backbone is created, a variety of clients could be modified or designed to make use of it (such as email, news, web, etc.).