[lines wrapped] On Wed, 2003-08-20 at 14:03, Thomas J. Boschloo wrote: > On Thu, 14 Aug 2003 13:22:21 -0400, Nick Mathewson <nickm@freehaven.net> wrote: [...] > > - When the protocol succeeds, it should create a directory > > signed by a large quorum of directory servers. If at least > > half of the quorum has signed a directory, clients should be > > able to trust that directory. (oops, this should be "greater than half".) > > See Steve's point. This seems rather arbitrary to me. Why only half and > not e.g. 75%? Why not 80%? "Greater than half" guarantees that if there are multiple competing fragments of a quorum signing different directories, no more than one of those fragments will be trusted by the clients. Also note that if we require votes to be made by a majority, but signatures to be made by more than a majority, nodes in the minority can effectively spoil any vote they don't like by refusing to sign the result. [...] I'm skipping some points about attackers taking over the voting quorum, since I've talked about that pretty heavily in my last messages to the list. > > - If a directory server do not obey the protocol, other servers > > should be able to prove it. > > Seems like a recipy for trouble if you asked me! Divide and Conquer is > what is happening in APA-S already. I think it is best not to point > fingers and for directory server administrators to keep a low profile > instead of fighting with other directory servers, if only to keep > mailing lists like this readable. That's why misbehavior should be *provable.* If a directory server is behaving incorrectly, the other servers' administrators should have proof (in this case, a set of inconsistent signed statements from the broken directory). Because the statements are signed, the administrator of a directory server could not pretend that all was well. In her defense, she would have to say something like "My private key was compromised"; "My software was buggy"; or so on. (In practice, directory software should output messages like "Directory X seems to be confused/behaving strangely/..." instead of "Directory X is cheating.") > > 2.3. What directory servers know > > > - Whether it considers the mix 'credible'. (A mix is 'credible' > > if the directory server thinks it is honest. Different > > directory servers may have different criteria here: Some > > directory servers will consider new mixes as automatically > > 'credible' unless they have evidence of their dishonesty; > > others will consider new mixes as 'non-credible' at first, > > and list them as 'credible' after a probationary period.) > > This seems also to cause more problems than it solves IMO. Honest means > that a mix tries to be reliable -> which it can't guaranty depending > on his ISP; it does not attack the network -> which at least cannot be > proved (or disproved) in the current mixmaster network; and it doesn't > break users' anonimity. > > If this credibility becomes automated in clients, I forsee lots of > trouble in arriving at a single directory each day. Every directory > server admin will have it's own set of 'credible' and 'honest' mixes. > It might even not be the fault of a certain mix that it loses mail. > The fault might also be on the receiving or even sending side which > might lead to a lot of finger pointing and unhealty discussions (high > bloodpressure kind of discussions). (Note: Reliability is not the same as honesty -- you might want to read the document again. A mix is 'reliable' if it obeys the protocol and relays messages correctly. A mix is 'honest' if it isn't trying to break people's anonymity. A mix is 'credible' to you if you guess it's honest.) The 'credibility' structure is designed to prevent an attacker from signing up a thousand mixes, and having them all appear on directories once they're judged to be reliable. Right now, if a statistics server thinks a mix is dishonest, it doesn't list it. With agreement, however, the isn't possible -- the protocol treats unlisting a server as not knowing about it, and fills in the gap in your knowledge. It's true that different directory servers may have different standards of knowledge, and thus judge different mixes' honesty differently. IMO that's okay. If less than half of the voting quorum directory servers think you're credible, you're not credible. If more than half think you're credible, you're credible. If the quorum makes bad choices, you're always free to get some likeminded friends, start your own, and convince people to trust you instead. [...] > Oops, I suddenly (reading 2.4 and having some thoughts about Hall of > Fame lists at the directory servers in an attempt to 'sort' them > deterministically) realize some way to seriously destroy the mixminion > network. It would be possible to totally DoS like half the servers on > 'todays' directory, which will make them unhonest and skipped the next > day, No, it would make them not "unhonest" but instead somewhat "unreliable": re-read the definitions. Furthermore, slowing down a server for one day does not cancel out its history of reliability; see what Echolot does. > and then the remaining half (or a quarter) could be DoSsed. I > don't think mixmaster is this vulnerable because the keys last longer > and it is hard to flood all the remailers at once (though some do go > down after an attack IIRC from the past in APA-S). Just a troubling > thought.. (Note: If you can DoS half of the servers on any mix network, and people use message paths of any appreciable length, you can already keep the system from running.) The issues here are similar to some examined in http://freehaven.net/doc/casc-rep/casc-rep.pdf http://freehaven.net/doc/mix-acc/mix-acc.pdf Any working solution to them would be much appreciated, from any quarter. -- Nick
Attachment:
signature.asc
Description: This is a digitally signed message part