Re: remailer spam throttle

[dlv@bwalk.dm.com (Dr.Dimitri Vulis KOTM)]

[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?

---

<a href="mailto:dlv@bwalk.dm.com">Dr.Dimitri Vulis KOTM</a>
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps