Re: [tor-dev] Proposal Idea: Consensus Options

[Nick Mathewson <nickm@xxxxxxxxxxxx>]

On Mon, Feb 11, 2019 at 7:00 AM teor <teor@xxxxxxxxxx> wrote:
>
> Hi all,
>
> I have a Tor proposal idea: we should make it easier for tor to get options from the consensus.
>
> At the moment, a few tor options are set from the consensus. (If they aren't already set in the torrc.) But there's no abstraction in tor's code, so they're all implemented slightly differently.
>
> We could refactor the code so these options are much easier to declare. And we could provide a graceful upgrade path from off-by-default features, to on-by-default features.


Hi, Teor!

This is a cool idea, and something to think about as we refactor the
configuration handling code.

One area I'd want a proposal like this to consider is what we'd be
expecting other implementations of the Tor protocol to do.  If we put
an option-setting-feature into the consensus like this, does that
option's behavior in Tor become part of the spec?  I think the
simplest answer here is "yes, the option must be documented as part of
the spec".


> 1. Tor refactoring
>
> We refactor the tor config code, so that options can be declared as consensus options. If the option is configured locally, that value is used. Otherwise, the consensus value is used. If there is no configured or consensus value, the default is used.
>
> Each entry in the option declaration table would need 3 extra values:
> * a flag that tells tor whether to check the consensus
> * a minimum permitted value from the consensus
> * a maximum permitted value from the consensus
>
> At the same time, we might also want to:
> * declare a minimum and maximum value for all options, not just the consensus options
> * add a log message fragment that explains the value restriction

I'd also suggest that we also have an entry that tells us which
consensus parameter to look at, so that the consensus name doesn't
need to be the same as the option's name.  We'd need this for backward
compatibility at any rate.

> So far, this is a refactoring idea. But here's where it gets interesting…
>
> 2. Tor authority behaviour change
>
> We also want to gracefully upgrade new features, so that they are on-by-default.
>
> For privacy sensitive features, we would keep the current process:
> 1. Deploy the feature off-by-default, but make it a consensus option
> 2. Manually change the consensus parameter so the option is on-by-default
> 3. Change the next release of Tor so the option is on-by-default
> 4. When all supported Tor versions have the feature on-by-default, manually remove the consensus parameter
>
> This upgrade path allows us to make sure that almost all the network has the same behaviour.
>
> But for other features, we could upgrade faster:
> 1. Deploy the feature off-by-default, but make it a consensus option
> 2. Change the next release of Tor so the option is on-by-default
> 3. When the authorities upgrade to the next release, they automatically vote the consensus parameter on-by-default
> 4. When all supported Tor versions have the feature on-by-default, remove the flag telling authorities to write the consensus parameter from the option
> 5. When the authorities upgrade to the next release, they automatically stop voting for the consensus parameter
>
> This upgrade path turns the option on when a majority of authorities upgrade. We wouldn't be able to use it for options where flapping is an issue.

Relatedly (?), one case that we sometimes have wanted in the past is
the ability to disable an option or enable it for only a range set of
versions.  For example, we'd implement an off-by-default feature as a
consensus option ... and then discover some bug in the implementation
of that feature before we turned it on.


--
Nick
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev