RE: First go at directory server details

["Lucky Green" <shamrock@cypherpunks.to>]

Roger wrote:
> There are $d$ redundant directory servers, where d is like 5.
> When a new remailer wants to join the network, it broadcasts 
> its serverdesc to all dirservers. When a dirserver receives a 
> serverdesc from a new remailer, it broadcasts it to all 
> dirservers. Thus either a serverdesc is known by all honest 
> nodes, or it is known by no honest nodes.

An honest server node, due to transient network problems or active
attack, may fail to receive the server descriptors from the new minion
node and during the broadcast.

> Each honest dirserver now has the same list of alleged
> serverdescs in the system.

I suspect that guaranteeing that each directory server has the same list
of nodes, and making that fact verifiably by the users, may be quite
challenging. I also suspect that you will need to perform a multi-party
computation involving each directory server, publishing the results.

> Dishonest dirservers know about
> this list, and might know about some more too.

> Dirservers locally compute a list of \emph{active} nodes. A
> remailer node is active if it passes the reliability 
> (pinging) tests of that dirserver.
> 
> Each dirserver then broadcasts its list of active nodes to
> the other dirservers. There's a deadline each night by which 
> they must have done that. Then each dirserver locally 
> computes its version of the \emph{consensus directory} --- 
> say, it includes all nodes listed by at least 3 dirservers.

So the attacker would need to run 3 out of n directory servers to either
introduce fake nodes or potentially force the creating of different
consensus directories?

> Then it broadcasts it to the dirservers, along with a
> signature, and hashes of the active node lists it received 
> from the other nodes. If any the hashes are bad compares to 
> the active node list that dirserver got, the dirserver 
> operators are notified and freak out appropriately. Each 
> dirserver now puts the signatures together with the consensus 
> directory, and offers it to the world.
> 
> There's a deadline by which it must be available; this
> deadline is before the time when the new directory should be 
> used by clients. All remailer nodes must go fetch the new one 
> during this meantime.

I believe that users would be very unhappy if the old directory expires
and no new directory is available since no consensus can be reached
amongst the directory servers due to networking problems/attacks. Care
should be taken to avoid this situation even if a significant number of
directory servers are subject to a DoS or have gone hostile.

> Issues to elaborate on in the future:
> 
> 1) what happens if you want to add a dirserver?
> 
> It seems like you just add his signature to the distribution,
> and he starts signing consensus directories. People with the 
> old code won't care as long as they still meet threshold.

Users and even operators will be concerned about hard-coded directory
servers. That risk could be mitigated by ensuring that the hard-coded
servers are operated by relatively widely trusted parties. (I don't have
any suggestions as to who those parties should be at this time).

> 3) what if the dirservers disagree about who is a dirserver?
> 
> The ultimate question is, who decides which dirservers go
> into the distrib? And if there are multiple distribs, what 
> the heck do we do?

There can be only One?

--Lucky