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

Re: Draft: Directory agreement in Type III



[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