In message <199408042200.SAA07928@cs.oberlin.edu> Jonathan Rochkind writes:
* Rochkind's stability-from-being-paid and web-of-trust notions
I'm not sure I like being credited with the "stability from being paid" notion. I think there _is_ stability from being paid, but I think if the infrastructure depends on it, it's not a good infrastructure.
If you look at the history of the Internet, there have been some free Internet services, but the ones that have thrived have been paid. (If the government or your school subsidizes your Internet access, it may appear free to you, but the staff all get their paychecks every month.
The system should be able to create a stable top-level infrastructure on top of an inherently instable environment, with remailers going up and down, and popping into existence, and dying. It should route around dead remailers, like the internet itself.
If it is built like the Internet, it will do just that.
The use of alt.x groups to exchange gateway information does not seem to add anything to this system; in fact it would seem to make it easier to spoof the system.
It _would_ make it easier to spoof the system, but I think it does add several very important things: 1) New remailers can easily announce themselves to the remailernet. [Whether they are to be trusted or not should depend on pgp-signed keys and web of trust, but the newsgroup provides an way to announce yourself to the system, and have that announcment by automatically dealt with by all participating parties]
There are two things being blurred together here which should be kept distinct. The first is gateway-to-gateway announcements. The second is advertising of the RemailerNet gateways to the wider world. Generally I would expect gateways to introduce themselves to one another privately and negotiate an understanding. Part of this will normally take place off the Net. This is an infrequent event, and so can be time-consuming and expensive. The basic web of trust is that between gateways. Once gateways had entered into a relationship, there would be frequent encrypted private traffic between them which would maintain the trust. Gateways can also announce their presence to the wider world, and publish their public keys. This could be done in alt.RemailerNet or it could be done in alt.internet.services, or any of several other places, or all of these. Any information published in alt.RemailerNet would be suspect, because it could be a complete fabrication or it could be a modified version of the correct posting. Gateways could be started up by anyone and some postings to alt.RemailerNet would be spurious. The "gateway" could be a sink, just tossing traffic sent to it, or it could copy all messages to a TLA before forwarding them. The user-gateway web of trust would therefore be far more problematical. I think that this would function as a market, and unreliable and untrustworthy gateways would be driven out over time. At the same time, there would be a constant bubbling up of new remailer networks, because the software would be freely available and the protocols well defined. The longer lasting gateways that proved trustworthy would in time join established networks.
2) Users (not people operating remailers, people using them) could make use of the newsgroup, to compile a database of remailers, and make long remailer chains. Users could have automated software doing this.
Compiling a list of remailers, sure. But if you let the user control how messages are chained, you are inviting real traffic analysis. The user should only be able to specify his destination and the level of security desired.
[snip] These are really two facets of the one problem, of allowing a user or remailer who has just arrived on the seen to quickly get a list of remailers, and make use of them, all automatically. That's sort of the super-set problem which encompasses the other two, and whose solution solves the other two.
I don't think it's a coincidence that the newsgroup system solves these two problems at the expense of security (the newsgroup makes it easier to spoof).
If the newsgroup is used as described above, RemailerNet itself is not threatened; it is only the users that can be spoofed. This level of risk is unavoidable. But gateways would never use the newsgroup for inter-gateway communications, because (a) it would be redundant (they can talk directly once they know each other and (b) you would have to assume that anything posted to a newsgroup had been compromised.
The fact is, that even remailers exchanging mail _can_ be spoofed, if not quite as easily as the newsgroup idea. It seems to be a premise of cryptographic protocols and schemes, that you've got to assume a worst case and get a system working where even under the worst case, everything works.
Well ... if you follow this line of reasoning too far, you are just saying 'nothing can be trusted, so don't bother being careful'. If I were running a remailer and someone posted his address in a public newsgroup and said "hey, here I am, and I run a really good remailer" I wouldn't trust him just because he signed it. I would get in touch with him, ask around about him, maybe run some low-security traffic through his remailer for a while. Then after some time I would raise my estimate of his trustworthyness. If he dropped traffic, if someone reported that something that they had sent privately had been compromised, I would drop him.
I agree that it seems a good idea for the SMTP RFCs to be used to exchnage info, ... etc
You already use the SMTP RFCs to exchange information -- this message comes to you courtesy of those RFCs. Email can have very complex headers and they can be in pretty much any order. This makes it difficult to write email software. I am simply suggesting that we allow only the minimal few headers, with possibly a few added to support RemailerNet protocols. ASSIGNMENT OF ANONYMOUS IDs These types of traffic are possible, where 'known' means your ordinary email address: known --> known known --> anon anon --> known anon --> anon There should be two anonymous IDs, one for sending, one for receiving. I assume that anonymous IDs are never assigned automatically. If you want an anonymous ID pair, you ask the gateway for one, possibly enclosing your public key encrypted with the gateway's public key. The gateway returns your new IDs, encrypted if you you gave it a key. The 'send' anonymous ID is used for sending messages from someone else's account. The gateway converts it into a 'receive' ID before forwarding your message. The 'receive' ID appears on your email after it goes through the gateway and can also be passed to other parties who want to send you remailed messages. Additional security can be added by using a digital signature. The gateway could be instructed ignore messages lacking such a signature or to take some specified action. ELECTRONIC CASH Ecash is easily added to such a system. 'Emints' would generate a message containing a bank identifier and an encrypted value. This would be the ecash. It could be given to anyone or anything. Messages containing ecash would be encrypted. The emint would credit the account of the first person to present it, and would bounce any copies presented subsequently. Giving change would be trivial. -- Jim Dixon