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