More on remailers

[Ryan Lackey]

(wow, this is the most interesting discussion on cypherpunks in
months -- thanks Len!)

My security philosophy is:
   1) You need to make the set of people who can't
   provably not	have sent messages larger than is worth investigating.
   Ideally, make the set that of all internet users. The set of
   people who use remailers today is not big enough; the set of people
   who use a web-based anonymizing gateway easily could be.  The set
   of people who post binaries to usenet may be.

   You need to make it easy to join the set (use standard protocols,
   no client software, and ideally make it require no user knowledge
   of the deeper darker purpose behind it all), and make it worthwhile to
   join the set (ideally a non-security non-messaging benefit, like
   "cool porn" or whatever)

   2) 2-way communication is inherently much harder to secure, but
   is socially beneficial.  Without socially beneficial uses, it's
   going to be a long and unpleasant battle, as it will be very hard
   to attract users.  Regulation is NOT the reason PR matters;
   perception by users is.

   3) "Sending anonymous mail" is *not* a compelling end-user
   application on a wide scale;	nowhere	near "have all the music you
   want available for free", "have arbitrary prohibited pornography"
   or "pay people anonymously".   Sending anonymous mail is a niche
   app but is also interesting as it is the same as "send protocol
   messages for other protocols, such as electronic cash,
   anonymously".  Until there are real applications which can provide
   large user communities, communicating automatically, with a high
   desire for anonymity, the best chance is to create low-effort, 
   not-necessarily-low-security remailer systems which increase the
   user community to the largest extent, spreading the collusion set
   even though the average user could be vulnerable.

   4) Latency must be low.  Anonymous (or at least private) online
   chat is more interesting to
   users than email.  Feds own EFnet servers with regularity; people
   discuss plenty of interesting things on IRC, vs. most email.  But,
   anonymous or even encrypted chat systems are a good deal more
   complex than mail.  Also, low latency is good for messaging.
   Normal mail is "near realtime"; mixmaster is anything but.  (most
   of the people who are likely to be users of anonymity are more
   comfortable with chat than email anyway.

   5) User-Group is as interesting as User-User.  If you require
   something which is opt-in, it will be difficult to communicate with
   mailing lists.  Encrypted group chat is good.  Use gale! (www.gale.org)

(indeed, "develop e-cash to use as postage for remailers" is kind of
putting the cart before the horse; "develop remailers to use to
transport intermediate results of electronic cash operations" is the
proper causality, I think)

Being a wolf in sheep's clothing isn't very useful if you're not
surrounded by sheep -- one "sheep" in a desert would look pretty
suspicious.  However, to successfully be a wolf hiding in a herd
requires that you look like a sheep, at least to casual inspection.
It does not require that the sheep themselves be equipped to go toe to
toe with the shepherd's dog.

(rambling level 1, skip if you're bored)

I disagree that a remailer user is necessarily identifiable to "users
of remailers" using current systems...but if you require a means of
payment to send messages, you are increasing the difficulty in
avoiding being in that set.  (of course most remailer users today are
observable in communicating with most remailers)

If I were sending a "life or death" remailed message, I would focus on
being unobservable and unlinkable -- inject the message into the
remailer fabric using 802.11b access "borrowed", or a netcafe, or
breaking into an office at night, or sending out a worm which
transmits its encrypted payload at some point in the future, or
whatever else.  (it is important these activities do not draw
attention themselves).  I'm working on getting an nntp feed sorted out
for HavenCo; once that's done, remailer.havenco.com will pick up and
drop off messages encrypted in a newsgroup.  I'd consider using a web
frontend via a web anonymizer; more commercial focus seems to have
gone into web anonymization.

Assume all network feeds in and out of the top-20 remailers are
monitored.  (I'm not at all certain mine are, but in general)  Being
identified as a routine user of anonymous remailers would thus open
you up to in-person visits from agents on fishing expeditions, black
bag monitoring, etc.  Exactly what you don't want if you're
operating covertly.  A one-off current remailer message isn't a big
deal, but if you were to build an *application* on top of remailers,
like mailing out kiddie porn to people on request, or software serial
numbrs, or running an assassination politics server, the feds would be
more likely to step up covert monitoring to try to catch people than
to try to shut down the remailers themselves.  (perhaps I'm
overestimating the intelligence of the FBI, but In cases of defence
'tis best to weigh The enemy more mighty than he seems...)

(if this were underway, I think you'd see the remailers they couldn't
compromise dropping off due to unseen technical problems, difficulties
with upstream ISPs, flooding, spam using the remailer as an exit, or
perhaps other actions where the attackers involvement was deniable)

But -- none of these attacks compromise remailers themselves.  Even if
you put the remailers in bank vaults, being identified as a member of
the ~500-1000 regular users of remailers, where you need to have a
continuing involvement.

Thus, in *practice*, I don't see the remailer network of today as
being substantially more secure against likely threats than a single
very strong remailer which you trust.  If I trusted me, I'd be more
comfortable using a single-hop remailer accessed via a steganographic
channel than in using some DC-net, infinitely-untraceable-internally
fabric which only had 500 externally-visible users (of which I'd be
one).

I've had in testing a simple, secure SSL smtp/pop3/imap/webmail
system, which should be ready to go into production shortly.  I'm
putting more resources into that than into remailers because I think
the "market space" occupied by anon.penet.fi is far more socially
beneficial than the "market space" occupied by mixmaster remailers.  
Specifically:

(rambling verbosity 2, encouraged to skip)


0) Mixmaster is one-way.  This is only good for abuse, and a VERY
small number of socially beneficial uses.  Even in the cases of
"whistleblowing", a 2-way communications method is needed.  A two-way
system is much more socially beneficial; can more easily keep the service
as a whole operating, even if individual accounts are shut off for
abuse, by pointing at a large number of "redeeming" uses.  It's
ultimately a PR and a technical battle, not a legal one.

1) Mixmaster can't provide "AP-level" security, due to small user
population and collusion set; mail.havenco.com can and can't -- you
need to trust the operator somewhat more unless you encrypt all your
traffic, and normal means of access have inbuilt "pooling" in that
they're spooled on the server automatically.  If you access via covert
means, either a general web anonymizer, or encrypted dead-drop, or
whatever else, maybe it's a bit better.  Of course you can use both
for the best of both.

2) Mixmaster is fucking hard to use for 1-way messaging (and all this
new stuff about "use electronic stamps, spam filtering, etc." will go
even *farther* in the "hard to use" side).  mail.havenco.com is easier
to use than your isp, because we won't rename accounts when people buy
providers out, we support SSL cert based relaying so it works on the
road, etc.  The rules of getting apps actually deployed:
 * Provide a tool which supports a compelling application; providing a
 tool which is useless for the application of "being a first-class but
 anonymous participant in online foruns", or which is a *great*
 buggywhip or camel condom, is not the same thing.
 * Use existing infrastructure and standards to make it easier to
 develop, configure, and maintain -- don't re-invent TCP every time,
 don't make users install massive amounts of custom software to do
 something as simple as send and receive electronic mail with their
 client, etc.
 * Incremental improvement and get something out the door quickly,
 incorporate feedback

I think doing interesting new transports inter-remailer
is...interesting, especially from an intellectual and academic
standpoint.  Requiring that users participate as first-class nodes in
p2p systems, dc-nets, etc. is going to raise the bar to being a
remailer user quite a bit, and lower traffic.  Users who can do that
kind of investment can already send unobservable, unlinkable,
untraceable email with little effort.

3) Mixmaster messaging is unreliable.  A professionally maintained
mailbox server is highly reliable; even if transports are unreliable,
it can retransmit transparently.  Abusive apps don't care about
reliability; most socially compelling ones do.  (latency is an issue
too, and without more volume than mixmaster has now, you can't really
get away with low latency)

4) Mixmaster is fairly immune to "editorial" action on the part of
remops; there are too many of them, it's too difficult to do anything
to do them.  A centralized system allows various forms of censorship,
from accounts being shut off due to AUP violations (spamvertised
mailboxes), pressure being placed on the operator, etc.  My AUP is
simple:
 - No spam and no use as spamvertised dropbox
 - No child pornography (due to sealand local regulations)
 - No files > x KB (where x will initially be something small and
   increase) (technically enforced)
 - No attachments or binaries (for now) (technically enforced)
 - Resource limits (per-day message limits, check limits) (technically)
 - No mail bombing or other malicious activity (rate-limiting)
 - dest.blk maintained by server operator on a per-user and systemwide basis
 - AUP violations result on forfeit of funds on deposit and deletion
   of account, but no information turned over (initially you must take
   this on faith/apathy, but later, the management UI will just have a
   "delete account" button and no way to subvert access control and read
   mail without breaking hardware tamper-resistance)

5) For a professional ISP, mixmaster is a bitch to maintain,
vs. cyrus/postfix/etc. which are designed to scale to lots of users,
are easily maintained, etc.

6) Mixmaster has no clear revenue model.  A system which is "sticky",
with people getting mailboxes, and persistent communications with
expectation of support from the server operator, easily allows
charging on a bulk basis.  "micropayments" are crap.  We've already
determined people won't pay large amounts for mixmaster remailers
because it doesn't support high-value applications and doesn't support
any compelling general applications, and collecting small payments is
a hassle.  There are plenty of ways to expand on a professional
offshore secure mail service as well -- think "critical path done well".

7) Having an organization with press/legal/etc. resources supporting a
remailer is more likely to get positive PR spin than a loose
collection of amateur remailer operators.  Also, of course, more risk.

8) Mixmaster as operated now has no love from the network operator
community.  People are abusing "no servers" accounts, for the most
part, to run high-hassle servers on subnets.  If *I* were running a
$20/month dialup ISP, I'd shut people off for running remailers.  It
breaks terms of service, which breaks revenue models for network operators.

9) Vanity domains, group messaging, etc. are not possible with
mixmaster or reply blocks.

10) Mixmaster has been tried for a while, and seems to "work", but
doesn't really do the kind of things which anon.penet.fi did.  I'd
rather give a different approach a try -- deploy something technically
inferior in some ways to mixmaster, but better from a user
perspective, and then armor-plate it later.

(rambling level 3, even more skipable)

I was actually holding off for a while to provide
this service commercially because someone else claimed to be working
on a public-access mail system which would have also been suitable.
However, that system is unlikely to be deployed beyond their insiders,
and is a complex scripted thing which doesn't do the specific task I
want, so I see no reason to delay.

My main concern is minimal support overhead.  If I give away free
accounts, I fear people will use them for spam dropboxes, and we'll be
spending all our time deleting those accounts.  Thus, I really need
something which has a substantial up-front investment to open an
account -- install fee, prepayment, or anti-spam bond;
proof-of-human-work; reputation; etc.  My initial thought is that I'll
give accounts to some well-known people if they want access, and sell
accounts for a high but not insane rate -- USD 200/year for an
offshore mailbox with SSL web/smtp/pop3/imap access seems reasonable.
I will adjust pricing based on demand, resources, etc.  I don't
actually need to make any money off of this; our colo sales are
sufficient, and I can consider it an advertising expense and
entertainment for me, but dealing with spam is not entertainment.

People who care can use this system in a highly privacy protecting
way...encrypt everything with PGP locally, interact entirely via
deaddrop, pay for service anonymously, use a domain maintained by
havenco vs. one they sign over in a registrar, send messages via
remailers as well.  People who just want a "secure" offshore mail
solution can send cleartext mail over SSL interactions with the
server.  The second set, I believe, is far larger, and is doing more
socially beneficial things with their access, and provides cover
traffic for the first set as well.
-- 
Ryan Lackey [RL7618 RL5931-RIPE]	ryan at havenco.com
CTO and Co-founder, HavenCo Ltd.	+44 7970 633 277 
the free world just milliseconds away	http://www.havenco.com/
OpenPGP 4096: B8B8 3D95 F940 9760 C64B  DE90 07AD BE07 D2E0 301F