[I'm not advocating anything concrete; I'm just thinkout out loud] Hal Finney <hal@rain.org> writes:
dlv@bwalk.dm.com (Dr.Dimitri Vulis KOTM) writes:
With the present scheme, if a remailer is "raided", it has precious little interesting stuff on it at any one time. Now consider the scenario:
X sends 1000 copies of child porn/seditious libel to 100 people believed no to be using remailers right now. The remailer keeps the 100 e-mails onits hard disk and e-mails each receipient a ping, inviting them to agree to the disclaimer terms and to retrieve their anonymous e-mail. The first recipie to retrieve the e-mail gets upset and contacts the feds. The feds figure, remailer still has the 99 other e-mails and the information on who's suppos to receive them in its queue; why not seize it and take a look.
This is a potential problem, but there are some other considerations. [valid points snipped]
I'm sorry, my scenario was superfluous. Even with ordinary remailer traffic, if you institute the policy that a first-time recipient gets a ping and his e-mail is kept at the remailer until he decides that he wants to accept qnonymous e-mail - there will be quite a bit of such letters at the remailer, making it a more attractive target for search+seizure. (Even if they're all encrypted and sans recipients, there's just more interesting stuff for the fuzz to look at than there is now.) That's why I feel that it's time to change the remailer model and to discard e-mail addressed to recipients not known to be willing to receive anonymous e-mail. Instead, send them a form letter explaining how they can get future anon e-mail if they want to. BTW: the remailer doesn't need to know whether the recipient is the end recipient or another remailer. We can safely assume that every remailer has a key on some key server.
More generally, I think we need to keep in mind what a remailer does and what it doesn't do. The essential function of the remailer is to provide anonymity via mixing messages. It does not provide confidentiality of message contents. That has to be taken care of by encryption. And, as I wrote yesterday, it doesn't (can't) keep secret who the people are who send and receive anonymous mail. All it can do is to disguise which particular people send and receive to each other.
I agree, but: I'm not ecven talking about making traffic analysis harder or easier. Rather, I don't want to add a new vulnerability by keeping around a relatively short list of people willing to receive anonymous e-mail.
The same is true of a DC-net or a perfect Chaumian mixnet. These systems do not disguise their particpants, or protect the confidentiality of their message contents; they only hide the knowledge of who is talking to whom.
Well - it's bad that someone can monitor the outgoing e-mail from a given remailer and learn who actually gets it; it's worse if the attacker can see this remailer's list of _potential recipients (some of whom might not be getting any mail during the monitoring period).
There's a big distributed database of pgp keys on the several keyservers. Add a bit to the database specifying whether the key owner wants to receive anonymous e-mail. By default set it to true for the existing addresses.
(The "default true" is going to allow the same kinds of abuse which we have seen in the past. Some remailers may be able to tolerate this, but as we have seen, many can't.)
I'm not sure about this point, so I'm not necessarily arguing. However I expect that the vast majority of people with enough clue to get their key into a key server are likely to be more enlightened than the average user today. I definitely feel that someone without enough clue to do that should NOT be forwarded any e-mail. If this idea of using key servers for dest blocking is indeed adopted, then we could first try "default true" and if the problems we have now persist, then make it "default false" and require a positive action by the recipient. The problem with a separate positive action is that there will be an initial period when the pool of users who choose to receive anon e-mail is small (under 100). Some LEA investigating an internet- related crime just might decide it's worth his while to pay a close attention to these people (regular police work :-). I'd rather start with a pool of enabled destination so large that it's not feasible to investigate each one for just being in the pool.
When the final remailer in the chain wants to send someone an anonymous message, it attempts to retrieve a key from the keyservers.
If it fails to find a key, it junks the mail (you don't want to keep it around, it's baiting the LEAs!) and instead sends a notification to the recipient that some anon e-mail was addressed to it, but it was junked; and if they want to receive anon e-mail, they need to give a pgp key to one of the key servers this remailer uses.
This is what I like. It's a lot simpler than trying to keep a copy of the anonymous mail and deliver it later when the person asks for it. Just let him know that someone is trying to reach him anonymously, and let him enable that if he wants to be able to receive the next anonymous message that comes in for him. You can load his permission message down with all kinds of disclaimers that say he knows he's likely to receive obscene, threatening and illegal material, that he doesn't mind, that he knows the remailer is an automated system which doesn't look at the contents, etc. Not only does this give you a defense but it makes the person think about what he's getting into, so he will in fact be better prepared when something bad comes his way.
Yes! Plus, someone with enough clue to make a key is hopefully less likely to be a total twit.
Plus, having taken positive action to enable receiving anonymous mail, he will hopefully be more knowledgable about how to request that you stop, and it won't be such a big deal. He opens the pipe, and if he gets a face full of sewage, he closes up the pipe right away. You warned him.
If it finds a key, it looks at the anon mail bit; if it's on, it encrypts the e-mail with the recipient's key and sends it; otherwise it junks it.
Obviously, the key servers would need to be modified to allow users to specify whether they want anon e-mail when then store their keys, and to change this setting any time.
Key servers wouldn't be the only place to store this information. I think the remailer could keep its own list, especially if it were defaulting to "off". This way recipients wouldn't have to generate and submit PGP keys, which is more work than just sending a reply to a remailer giving the OK to receive anonymous mail.
I think that the side effect of encouraging people who haven't generated and submitted PGP keys to do so (and requiring them to use PGP to read the mail once it comes in) is a desirable side effect. I also think that the maintenance of dest blocking needs to be removed as far as possible from the remailer operations. Remailers are subjected to high turnover. Do new operators really collect dest blocks from the existing ones? Does a user sending a single blocking request to one of the mailing list get blocked from all existing remailers? Could some paranoid LEA subpoena dest blocks from all the existing remailers hoping to learn something by comparing them? If I were running a remailer, I'd prefer to rely on someone else, someone centralized, to process destination blocking requests (and to authenticate them - as Adam pointed out, the fact that we now don't authenticate dest blocking requests is bad, very bad).
Right now, there's a very large number of addresses in the key servers. Instantly making them into a list of addresses that accept anon mail will make it hard (hopefully infeasible) for the LEAs to investigate everyone willing to accept anon e-mail as a suspect in sending it.
More cautious or politically vulnerable remailers might default in the other direction. It would be a matter of the individual situation.
Hmm. Just thinking out loud. Suppose Alice and Bob both run remailers. Alice has "default true" and Bob has "default false". (Either is much more cautious than the present setup, of course.) Someone sends e-mail to Carol with Alice's remailer as the final one. Carol had previously given her key to some key server known to Alice's remailer, so she gets the e-mail. Next, someone sends e-mail to Carol via Bob's remailer, who discards the e-mail and tells Carol: "I see your key, but I don't see your positive action to get e-mail." If I were Carol, I'd be somewhat pissed that my mail was lost. But of course it's up to Bob... Problem is, if the key servers actually allow 3 values in that field: explicit true, explicit false, default; then again for some time the list of people with explicit true will be small enough to investigate just for this reason. To protect recipients' privacy, I'd rather set anon mail to true for all existing keys. To do what I've described requires 1) a change to the remailers, 2) a change to the key servers. Are there any people who run key servers on this list? --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps