Re: remailer spam throttle

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 not
> 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 recipient
> to retrieve the e-mail gets upset and contacts the feds.  The feds figure, the
> remailer still has the 99 other e-mails and the information on who's supposed
> 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.

First, there is no particular reason why one recipient of some email from
the remailer should know or even suspect that other people have the same
email waiting.

Then, to defend against raids like this, the material could be separately
encrypted to each recipient.  There would be no way to know that material
sent to one recipient matched material sent to someone else.  The raiders
would just find a bunch of encrypted files.

Of course, if it were a sting operation, with the recipients being lured
or entrapped into requesting information they shouldn't, then the sender
might avoid using these countermeasures.  However, there wouldn't really
be any need to use a remailer for a sting operation like this, it could
be done just by offering the material from an ordinary address.

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.

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.

Having said that, I do like some aspects of this idea:

> 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.)

> 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.

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.

> 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.

Hal

[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