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

Re: Brief argument for directory agreement [was Re: Sending unique/recogniziable remailer keys to suspect mixminion users]

On Wed, 20 Aug 2003 14:49:57 -0400, Nick Mathewson <nickm@freehaven.net> wrote:


On Wed, 2003-08-20 at 14:02, Thomas J. Boschloo wrote:

[snip answer pointers to dir-spec.txt 5.2 and dir-agreement.txt 2.1, I will check them out next time I go online, I am beginning to grasp more and more on how directory services work in mixminion, sorry for getting on to this so slowly and wasting everybodies time by not reading all these documents well..]


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.)

I think it is good that there is no hierarchy of directory servers with one main server controlling the others (if any).


- 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.

Still, I would like such a possibility (having clients download from multiple servers). It could perhaps be made deterministic by downloading in a fixed order, like sorted on IP adresses of the directory servers. It would be like downloading all messages from alt.anonymous.messages pointed to by a nym account. This is considered to be the safest mode of using the Frans Kaashoek nyms in APA-S. I will talk more on this later on (unless the group can strike down this suggestion at sight).

I mean, you do download from every directory server you know about (could perhaps be specified in the signed directory postings themselves), and drop what you are not using. Also should work great when certain servers are inaccessible from the clients provider. Might be a problem though if there are too many servers to choose from, in which case the partitioning attack would be very dangerous for the clients anonimity. Maybe this could be solved by downloading only from the 'fittest' (Darwin fittest) servers of the previous day, which is something all the servers should then agree on, but this seems like a slippery slope to me. Another possibility would be to use the current mixminion system to arrive at a maximum of e.g. 10 servers. Maybe it could just safely be ignored till the time arrives when the number of directory servers becomes too big.


- 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.

The trust decisions alone would partition the users, but see above on choosing *all* servers instead of *several* ;-)


- 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.

But the way I see it, this could be prevented by having a counter on each server that is derived from the day the server started operating multiplied by what portion of time it has been online since then. Other servers should have this figure start at 0 and increased once a day if the server was active during that day. That way the directory server admin should be unable to start with a very high figure and older directory servers would become more 'autoritive', which should be a cool reason for aspiring admins to join in the program soon.

If loads of servers start at the same day, this would show in the stats. Like after 9-11-2001 the number of remailers doubled within a few months. Anyways, such a stat should be fun to include in the mixminion protocol anyways. New servers should IMO rate all other servers as day 0 since they have no way of knowing it to be otherwise!


- 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.

I recently read an article on IRC in the C'T, and I wonder if the list of directory servers could be maintained by the 'invite' system in IRC. This technology has proven itself, but what I do not like about it is how it would depend on humans to invite new directory servers. Still, it would be a very social way of introducing and kicking directory servers with multiple 'operators' (a newly added directory server need not get 'operator' status the first time it joins IMO).

Just a thought (I am having loads of them today, drank too much coffee this morning I guess).

[snip some]

Oh, I think I will start a new post on directory servers how I would intuitively model them, because this one seems to get a bit long..

Regards and thanks for reading,
Thomas
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/