On Wed, 2003-08-20 at 14:02, Thomas J. Boschloo wrote:
[Lines wrapped.]
[...]
> By now I have read the relevant parts in the mixminion pdf, and I see that
> 1) directory servers use /complete/ directories [pdf 6]
> 2) a treshhold of directory servers will remain honest [pdf 4]
>
> Honestly, I think 1) is undoable and that 2) is quite an assumption to
> make as I hopefully pointed out in my previous post. I must admit that
> I am not totally clear on the details of these directory servers
> though. Like how does a node advertise itself?
See dir-spec.txt, section 5.2., "Publishing a server descriptor." This
has implemented in Mixminion since version 0.0.4.
> And to which servers?
See dir-agreement.txt, section 2.1.:
Mixes upload their server descriptors to directory servers as
before. The only change is that every Mix now knows about a
number of directory servers, and uploads every descriptor it
generates to each one of them.
[...]
> A thought I had today is the question if a situation where more than
> one entities try to gain control over the network by the process of 1)
> incomplete/inaccurate directories, 2) making sure they control most of
> the directory servers + some mixminion nodes,,
This is basically what the protocol is designed to resist. Here's an
outline of how I arrived at the build-quorums-and-vote system -- with
luck, it will answer your question.
- A single directory server is simple, but no good -- it's too easy for
a single server to be corrupted. (On the bright side, if the server
_is_ uncorrupted, it's easy to trust it.)
- We could have multiple uncoordinated directory servers, but that would
partition clients based on node choice. If any directory servers are
corrupt, they can mislead clients who trust them into being especially
distinguishable.
- We could have multiple uncoordinated directory servers, and rely on
clients to choose *several* servers, and reconcile their directories on
the client side. This would make clients even more partitionable than
before, and also require clients to make tricky trust decisions.
- We could have an _open_ set of coordinated directory servers, and
allow anybody to join or leave. In this case, an attacker could (as you
describe) take over the coordinated directory by signing up many servers
and discrediting existing servers.
- We could have a _closed_ set of coordinated directory servers, and not
allow any serves to join or leave. This system would be secure (if
enough of the servers were trustworthy), but it's fragile. Of special
concern are the social engineering attacks you mention: an attacker
could prevent the directory from being generated by getting members of
the closed group to disagree about who the members are.
- [The approach I like.] We have a semi-closed set of coordinated
directory server. New servers can join based on the consensus of the
existing members. If a bunch of new servers decide to start their own
semi-closed set, then
I think that the protocol I've outlined resists social engineering
attacks fairly well, for these reasons:
1. In order to be a member in a voting quorum, you must agree with
all the members of that quorum about who the voting members are.
2. When a single trust relationship is removed from a quorum, the
'friendliness' criterion favors removing the member who broke
the relationship, until there is a unique largest subquorum.
(In other words, if N1...N5 all trust one another, and N1 drops
his trust relationship to N2, *N1* is removed from the quorum.
On the other hand, if N1 and N2 stop trusting N3, *N3* is
removed from the quorum.)
3.
> I just wonder if it
> would be possible for two such entities, which would not know about
> each other, to cancel each other out.
Attachment:
signature.asc
Description: This is a digitally signed message part