On Sun, Dec 22, 2013 at 10:27 AM, Karsten Loesing karsten@torproject.org wrote:
On 12/17/13 10:31 PM, Nick Mathewson wrote:
165 Easy migration for voting authority sets
This is a design for how to change the set of authorities without having a flag day where the authority operators all reconfigure their authorities at once. It needs more discussion. One difficulty here is that we aren't talking much about changing the set of authorities, but that may be a chicken-and-egg issue, since changing the set is so onerous. If anybody is interested, it would be great to move the discussion ahead here. (5/2011)Hi Nick,
(just in case you're wondering, I'm going through all proposals in your list that have to do with the directory protocol and try to review them)
Proposal 165 looks like a fine idea, and the algorithm looks plausible to me. I'd say let's do it!
So, what discussion would you want to see here? Are you hoping for some kind of "proof" that the suggested algorithm cannot break under certain assumptions? I don't know how to write one. But this could be a fine question for a grad student or researcher. For example, a few days ago we have been asked for research questions for small doctoral projects, and this could be a fine topic.
Maybe; I'm not sure I'd want to have anybody do this for their doctoral thesis and expect that the results would be important to Tor. (IOW, Tor could use a solution here, but we're not suffering from the lack of it. Further, anything that's much more complex than the scheme in 165 is probably not going to get implemented, and I wouldn't want to disappoint a PhD candidate through giving them inaccurate expectations.)
I'm not expecting a proof that the scheme described in prop165 works in any robust way given byzantine inputs; rather, I just want to be sure that it works properly if a majority of authorities are configured correctly. And I believe it does.
Also, there's an issue we should solve. It says,
Ties are broken in favor of some arbitrary function of the identity keys of the authorities in the set.
We should specify which arbitrary function we mean, and describe how it works when we do a migration where we _replace_ an authority.
Or did you expect to hear from current and prospective authority operators? As a former authority operator I can say that I'd really have appreciated a two-phase process where everyone first configures a second voting set and then removes the first voting set.
Or were you hoping for somebody to implement the proposal? Doesn't seem terribly difficult, so maybe we'd find somebody if we created a Trac ticket for it.
Agreed. The trickiest parts will IMO be:
1) Handling the fact that we can know about directory authorities which are not the directory authorities we treat as canonical. Right now, we have only one set of authorities we believe in. That would need to broaden into three sets. First "prospective co-voters" would be the authorities to which we send our votes, from which we download votes, from which the authorities we download certificates (?). "Actual co-voters" would be the set whose votes we use as input to our consensus, and whom we collect signatures signatures from. Finally, we'd maintain the set of authorities that we believe in as a regular Tor node, which we use for checking consensuses.
2) Testing!
Here's some feedback, though nothing really important:
- Branch prop165tweaks in my public torspec repository has a few tweaks.
Merged.
- You say in "Migration issues" that we should keep track somewhere
which Tor client versions recognized which authorities. Would it be sufficient to write a little shell script that searches the git history of config.c for changes to trusted authorities and prints out which tags first contained those commits.
Maybe, though that script would need to parse C to stay viable long-term. Better IMO to introduce a little change log comment around that part of the code. Possibly it could be built using such a shell script, though.
peace,