[tor-dev] Review of Proposal 165: Easy migration for voting authority sets (was: Tor proposal status (December 2013))

[Nick Mathewson]

On Sun, Dec 22, 2013 at 10:27 AM, Karsten Loesing
<karsten at 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,
-- 
Nick