Fyi for those wondering about the logistics of rotating directory authorities (and why it is more complicated and more fragile than you may have expected :).

--Roger

----- Forwarded message from Roger Dingledine arma@mit.edu -----

Date: Fri, 1 Jul 2016 13:31:46 -0400 From: Roger Dingledine arma@mit.edu To: dir-auth@lists.torproject.org Subject: Plan for dropping urras: starts with dizum, Faravahar, dannenberg

--------------------------------------------------------------------------

We're going to do this in three phases.

PHASE ONE: a) dizum, Faravahar, and dannenberg all drop urras from their DirServers lines. There's no need to synchronize here -- just do it as soon as you get around to it, and let us know that you did.

PHASE TWO: once all of phase one is done, then moria1, gabelmoo, and longclaw will do a coordinated switch in the same hour.

PHASE THREE: maatuska and tor26 will switch whenever they like after that.

--------------------------------------------------------------------------

Here are all the details so you can follow along with why I think this will work, and how it can go wrong.

Constraint 1: We have nine dir auths currently, and we need five of them to agree in order to get a consensus.

Constraint 2: Five of the nine have attached bandwidth authorities, and we need three bwauths to be part of the consensus at all times.

Constraint 3: Five of them vote on BadExit, and we need at least one of them in the consensus or we unassign all the BadExit flags. An odd number of voters (one or three) is better than an even number (two).

Constraint 4: Three of them vote about recommended versions, and we need at least one of them in the consensus.

Constraint 5: Each authority supports a range of consensus methods depending on what Tor version it runs. When constructing a consensus, the authorities choose the largest consensus method supported by more than 2/3 of the voting authorities for that hour. Now that dizum has upgraded to Tor 0.2.8.x, we'll have 9 authorities that can do method 20 and 4 authorities that can do method 22, which means we'll pick method 20 so long as there are at least 6 authorities voting. We should make sure that nobody else upgrades to Tor 0.2.8.x until we've finished, else we could fall into an edge case where we have enough that we pick method 22, but not enough to get five signatures on the resulting consensus.

Constraint 6: Tor versions before 0.2.8.1-alpha don't believe in dannenberg's current v3 identity key, and Tor versions before 0.2.4.26 or 0.2.5.11 don't believe in longclaw at all. The dannenberg issue can be solved by having dannenberg resume voting with its legacy v3 identity key (I don't know why it stopped -- maybe it never started?), and the longclaw issue can be solved by declaring that versions that old don't matter to us.

With that in mind, here are our nine dir auths, with their properties, grouped into the three phases:

dizum no-bwauth method22 faravahar BWauth method20 dannenberg no-bwauth method20 only-believed-by-0.2.8

moria1 BWauth BadExit recommends-versions method22 gabelmoo BWauth BadExit recommends-versions method22 longclaw BWauth BadExit method20

maatuska BWauth BadExit method20 tor26 no-bwauth BadExit recommends-versions method22 urras no-bwauth method21

So once phase one is complete, we should still have six dir auths voting, including four bwauths and five badexit voters and two recommends-versions, and using consensus method 20.

Once phase two is complete, we should have six dir auths voting, including four bwauths and three badexit voters and two recommends-versions, and using consensus method 20.

The end of phase two will be the most delicate point, since most deployed Tors don't believe in dannenberg's new key, so while we will have six dir auths voting, most clients will consider the resulting consensus to have only five signatures -- so if anybody drops out we will not have enough signatures.

Once phase three is complete, we should have eight dir auths voting, including five bwauths and five badexit voters and three recommends-versions, and still using consensus method 20.

Whew. Let me know if any of my logic is bad.

--Roger

----- End forwarded message -----