Re: First go at directory server details

[Len Sassaman <rabbi@abditum.com>]

On Sat, 11 Jan 2003, Roger Dingledine 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.

Are you considering propogation delays? What if an attacker submits
altered serverdescs to various directory servers, in an attempt to keep
them too busy with broadcasts to reach consensus? Also, you must consider
that some directories may not be reachable by others directly.

What is the lifespan you are assuming for any given directory server?

> Each honest dirserver now has the same list of alleged serverdescs in
> the system. 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. 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.

You are assuming that the directory server admins will take an active role
in this process?

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

> Now, when the user downloads the mixminion client, it comes with $d$
> hard-coded keys, one for each dirserver. When he needs a current
> directory, he goes to his favorite node and pulls down the consensus
> dir. He verifies the sigs based on the public keys he knows, and if a
> threshold of them (3 as above) are correct, he accepts the directory.
> It doesn't matter which node he goes to, whether the node is evil, etc:
> a good directory is a good directory.

What happens when there are no active directory servers hardcoded in the
client, because the client hasn't been updated in 2 years, and all the
previously existing directory servers are dead?

> Again, you remove him from the distrib, and he can stop signing things.
> As long as we don't ditch too many at once, we should be ok. Of course,
> we shouldn't remove too many dirservers at once -- a removed dirserver
> is equivalent to a malicious silent dirserver, for a while.

And what damage, exactly, can a malicious silent dirserver do?

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

Ultimate questions indeed.

> 6) what about DoSing a dirserver, or otherwise screwing things up?

otherwise, such as falsifying ping data.

> As long as you don't DoS "too many" dirservers, then we don't care. But
> that's the problem: we need the threshold of acceptable signatures to
> be low so knocking out some dirservers doesn't cripple us, but we need
> it to be high so controlling some dirservers doesn't let you include
> arbitrary nodes.
>
> My instinct is to keep the threshold pretty low, on the theory that
> if we pick dirservers as our friends, more than a few malicious ones
> are unlikely.
>
> 7) degraded mode; or, what do you do when you can't get enough signatures
> for the day?
>
> Targetted DoS can affect anonymity. If you DoS the dirservers for
> even part of a day, you can generally reduce the set of nodes on the
> active list, since fewer pings get out, fewer responses return, etc.
> Targetted DoS against remailer nodes can push them under the threshold
> for being listed.

The clients aren't able to ping directly?

> A successful DoS against enough dirservers for a whole day means they're
> not going to create a useful consensus directory for the next day. This
> means that clients will fetch a new directory, find that it doesn't have
> a threshold of signatures, and freak out. As well they should -- there
> are enough unknowns already in terms of how much anonymity clients can
> reliably expect -- reducing it even further may mean that users shouldn't
> expect the usual anonymity from the system that day.

Users do not want to use clients which "freak out". "Freak out" is not an
acceptable mode of operation for an email client, period.