The Design, Implementation and Operation of an Email Pseudonym Server
Mazieres and Kaashoek

We're good at "correctness".
  E.g. ensure a message can't be read by the wrong person.

What about liveness?
  E.g. that the message *can* be read by the right person?
  
nym.alias.net is a good case study:
  1. Don't want to log or keep much state.
  2. Provides tools useful in anonymous attacks.
  3. Easy to abuse, i.e. use for activities that will
     make people want to attack nym.alias.net.

What is the point?
  I want to send mail with disguised From that can be replied to.
  Recipient sees:
    From: foo@nym.alias.net
    To: user@x.com
  And replies to foo@nym.alias.net go to real originator.

Why not use Chaum's untraceable return addresses?
  It means the recipient has to have the right crypto software.
  And understand how to use it.
  We want only the anonymous user to have to use crypto.
    So anyone can send mail to xyzzy@nym.alias.net

Straw man implementation:
  nym server has a table mapping nyms to real e-mail addresses.
  Just fixes From address in one direction and To in the other.
  What's wrong with this?
    1. Authenticate configuration changes.
    2. Message contents on private side reveal real user to snooper.
    3. IP addresses on private side reveal user's host.
    4. Don't want nym operator to know or be forced to reveal mapping.

Real implementation:
  Fix #1 by remembering user's public key for each nym.
  Fix #2 w/ PGP public key encryption.
    In both directions.
  Fix #3 with indirection through remailers.
    Obvious in user -> nym-server direction.
    Why can we also anonymize *destination* in nym-server -> user direction?
  Same fix for #4.

Attack 1 (4.1):
  Annoying mail from nym to regular user.
  Apparently this never happened on nym server -- why not?
    *Nym* isn't a good source for harassment -- easy for user to block.
    So these attacks probably go through anonymizers.
  Allow destinations to block mail to them.
  This opens up:

Attack 2 (4.1):
  Trick anonymizer into blocking mail to a user who wants that mail.
  Fix: require blockee to authorize.
    But blockee may not have registered a public key?
    Send with a none that must be repeated in the reply.

Attack 3 (4.2):
  Exponential mail loop.
    Uses ability of one nym to have multiple reply blocks.
  Why can't nym server directly detect this? [mixes anonymize]
  Fixed with daily byte count limit, for reception.
  This opens up:

Attack 4 (4.2):
  Send too much data to a nym to trigger daily maximum.
  No real defense -- but hard to remain anonymous -- why?
    High traffic levels make it easy to trace someone?

Attack 5 (4.3):
  Nym user sends lots of compressed messages, fills up server disk.
  Defend with daily limit.

Attack 6 (4.4):
  Ordinary user sends lots of mail to the nym server, overloads nym server CPU.
    Maybe not an attack, just lots of spam.
    Example: one of those worms reporting back to owner.
  Can't defend with daily max bytes.
    Maybe to lots of different nyms.
  Can't log senders...
  Short-term per-sender limits.
    But sender can be randomized.
  Short-term per-sending-host limits.
  Can these be used to trick the nym server into penalizing the innocent?

Attack 7 (4.5):
  Lots of mail to help@nym.alias.net with fake From address.
  Why not use logs to find the real sender?
  Solution: quote request header in response.
    Gives targets what they need to know to deal themselves.
  Why couldn't the requests be made anonymously?
    Because want to put target in From line.

Attack 8 (4.6):
  Set up a nym that points to an innocent user.
    Subscribe nym to all kinds of junk mail.
  Why wouldn't target know to complain to nym.alias.net?
    Because mail sent via anonymizer.
  Solution: require confirmation of reply blocks.

Attack 9 (4.7):
  Create lots of nym accounts, run server out of disk &c.
  Too labor intensive:
    Create PGP key (otherwise easy to see duplicate accounts).
    Reply to confirmation e-mails.

Attack 10 (4.8):
  nym users receive lots of spam.
  Is this a DoS attack?
    Sort of, since it makes the nym system unattractive.
  Defense:
    Spam-trap account helps detect spamming mail servers.
    Reject/delay future mail from those servers.
  This opens up another attack:
    Get remailer onto the bad server list.

Attack 12 (4.9):
  Anti-spam activist faked messages from ordinary users
    to biz.mlm &c.
  Messages forged using anonymous remailers and mail->news gw.
  Targets hate spam, willing to do anything to stop it.
    Called up Jeff Schiller in the middle of the night.

Attack 13 (4.11):
  Someone posts child pornography from a nym.

Why did the system get lots of DoS attacks?
  Anonymity makes them more likely -- no responsibility.
  Hard to produce, easy to consume anonymously.
  Availability of amplification:
    Trick many innocent parties into participating.
    Trick some powerful system into relaying. (spammers...)
  In general, programmable 3rd party willing to do things for you.
  Can trick system's defenses into reacting incorrectly.
  Not everybody likes the ability to be anonymous.

Are there denial of service attacks outside of the Internet?
  How does the "real world" deal with them?

Is there something about the Internet that makes such attacks easier?
  I.e. easier than in the real world.
  DoS attack via post office?