[tor-dev] Proposal Idea: Consensus Options

[teor <teor@xxxxxxxxxx>]

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.

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

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.

Each option declaration would need one extra value:
* a flag that tells tor authorities whether to write to the consensus

If the consensus parameter is explicitly set on an authority, then it would override the default from the option declaration.

I think we could implement this proposal as part of Sponsor 31, which is about refactoring tor. We have some tickets for refactoring tor's config code, and making it easier to implement optional features.

If anyone wants to help me write it up, let me know!

T

-- 
teor
----------------------------------------------------------------------


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