[tor-dev] Proposal 215: Let the minimum consensus method change with time
nickm at freehaven.net
Mon Nov 19 14:58:08 UTC 2012
Title: Let the minimum consensus method change with time
Author: Nick Mathewson
Created: 15 Nov 2012
This proposal suggests that we drop the requirement that
authorities support the very old consensus method "1", and instead
move to a wider window of recognized consensus methods as Tor
1. Background and Motivation
When we designed the directory voting system, we added the notion
of "consensus method" so that we could smoothly upgrade the voting
process over time. We also said that all authorities must support
the consensus method '1', and must fall back to it if they don't
support the method that the supermajority of authorities will
Consensus method 1 is no longer viable for the Tor network. It
doesn't result in a microdescriptor consensus, and omits other
fields that clients need in order to work well. Consensus methods
under 12 have security issues, since they let a single authority
set a consensus parameter.
In the future, new consensus methods will be needed so that
microdescriptor-using clients can use IPv6 exits and ECC
onion-keys. Rolling back from those would degrade functionality.
We need a way to change the minimum consensus method over time.
I propose that we change the minimum consensus method about once
per release cycle, or once per ever other release cycle.
As a rule of thumb, let the minimum consensus method in Tor series
X be the highest method supported by the oldest version that
"anybody reasonable" would use for running an authority.
Typically, that's the stable version of the previous release
For flexibility, it might make sense to choose a slightly older
method, if falling back to that method wouldn't cause security
For example, while Tor 0.2.4.x is under development, authorities
should really not be running anything before Tor 0.2.3.x. Tor
0.2.3.x has supported consensus method 13 since 0.2.3.21-rc, so
it's okay for 0.2.4.x to require 13 as the minimum method. We even
might go back to method 12, since the worst outcome of not using 13
would be some warnings in client logs. Consensus method 12 was a
security improvement, so we don't want to roll back before that.
2.1. Behavior when the method used is one we don't know
The spec currently says that if an authority sees that a method
will be used that it doesn't support, it should act as if the
consensus method will be "1". This attempt will be doomed, since
the other authorities will be computing the consensus with a more
recent method, and any attempt to use method "1" won't get enough
Instead, let's say that authorities fall back to the most recent
method that they *do* support. This isn't any likelier to reach
consensus, but it is less likely to result in anybody signing
something they don't like.
3. Likely outcomes
If a bunch of authorities were to downgrade to a much older
version, all at once, then newer authorities would not be able to
sign the consensus they made. That's probably for the best: if a
bunch of authorities were to suddenly start running 0.2.0.x,
consensing along with them would be a poor idea.
We might choose a less narrow window of allowable method, when we
can do so securely. Maybe two release series, rather than one,
would be a good interval to do when the consensus format isn't
We might want to have the behavior when we see that everybody else
will be using a method we don't support be "Don't make a consensus
at all." That's harder to program, though.
More information about the tor-dev