[tor-dev] Proposal Idea: Consensus Options

[teor]

> On 21 Feb 2019, at 00:29, Nick Mathewson <nickm at alum.mit.edu> wrote:
> 
> On Mon, Feb 11, 2019 at 7:00 AM teor <teor at riseup.net> 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.
> 
> 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.

I agree: I thought of this after I sent the email.
(And then I forgot, because I was on leave.)

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

It seems like implementing versions in the consensus could get really
complicated.

Here's one way to deal with that scenario:
* When the fix is implemented, rename the consensus parameter (but
  keep the same torrc option name)
* Keep the old consensus parameter off, but set the new consensus
  parameter once we're sure the bug is fixed

For example:

Let's say that release 1.1.0 has a MakeTorFaster option, with a
MakeTorFaster consensus parameter. It's off by default, so the
authorities set MakeTorFaster=0.

But in release 1.3.0, we discover that 1.1.0 and 1.2.0 had a broken
MakeTorFaster implementation. So we fix MakeTorFaster in 1.3.0, and
call the fix MakeTorFaster_130 in the consensus.

The authorities start by setting MakeTorFaster=0 and
MakeTorFaster_130=0. Then, when we're happy with the fix, we set
MakeTorFaster_130=1. (But leave the broken option off.)

Then, 1.3.0 and later are configured with MakeTorFaster, but the
broken versions are not.

T
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20190221/21316d8d/attachment.sig>