[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Against needless options [Re: use regexp re-writes like mix (Re:Straw poll on "From:" lines) ]



On Sun, 2003-06-22 at 13:03, Adam Back wrote:
> > Q1. To everybody operating an exit node is: would you be willing to run
> > an exit node that worked this way?
> 
> Yes; I used to with mixmaster.

Cool.  Due to the lack of complaints, I'm going to make this mode the
sole supported mode for 0.0.5.

 [...]
> In mix 2.9 or whatever you can control this with regexps.  (You get
> regexps with string replace:

The problem here is that when different remailers provide different
rewriting policies, an attacker can use this fact to partition user sets
or draw more traffic to a compromised remailer. 

[You're probabily familiar with this argument already; I'm including it
so that everybody on the list understands why I don't want to do header
rewriting the Mixmaster way.]

One of the goals of the Type III design is to specify as much
distinguishable behavior as possible, in order to minimize certain
attacks.  These attacks include:

   * Server option partitioning attacks.  [When some nodes behave in
manner X, and some nodes behave in manner Y, an attacker who assumes
that some clients prefer X nodes and some prefer Y nodes can use this
assumption to assist traffic analysis.]

   * Server option traffic attacks.  [If option X is both popular and
hard to provide, a high-resourced attacker can exploit this fact by
running a server that provides option X, thus ensuring that a high
fraction of the network's traffic will flow through the attacker.]

   * Client option partitioning attacks.  [Inasmuch as one client's
average observable behavior over time differs from another's, an
attacker can use this added information to assist traffic analysis. 
Mix-nets use clients to hide traffic, and when clients behave
dissimilarly, they don't cover each other very well.]

   (The first and third points don't apply so much to the formatting of
From addresses, since users who use them are _necessarily_ statistically
distinguishable from one another at the exit point over time.  I'm
including them for the sake of completeness.)

Of course, some options are unavoidable.  In the complete absence of
choice, our system would become useless for communication, and all our
users would run someplace else.  But with this in mind, we still need to
scrutinize every change that makes clients and servers distinguishable.

Thus, my target is not a maximally flexible configuration language, but
rather a compromise that everybody is willing to live with.  I really
hope that the current design in E2E-spec.txt meets these requirements --
if there's another one that will please everyone even more, we should do
that instead.

Many thanks for your time,
-- 
Nick

Attachment: signature.asc
Description: This is a digitally signed message part