commit 07ca8670182464f24c587ec68a0dbdeb78dfccc5 Author: Nick Mathewson nickm@torproject.org Date: Mon Nov 19 09:55:43 2012 -0500
Add proposal 215: Let the minimum consensus method change with time --- proposals/000-index.txt | 2 + proposals/215-update-min-consensus-ver.txt | 94 ++++++++++++++++++++++++++++ 2 files changed, 96 insertions(+), 0 deletions(-)
diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 332b64d..caec770 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -135,6 +135,7 @@ Proposals by number: 212 Increase Acceptable Consensus Age [OPEN] 213 Remove stream-level sendmes from the design [OPEN] 214 Allow 4-byte circuit IDs in a new link protocol [OPEN] +215 Let the minimum consensus method change with time [OPEN]
Proposals by status: @@ -186,6 +187,7 @@ Proposals by status: 212 Increase Acceptable Consensus Age [for 0.2.4.x+] 213 Remove stream-level sendmes from the design 214 Allow 4-byte circuit IDs in a new link protocol + 215 Let the minimum consensus method change with time ACCEPTED: 117 IPv6 exits [for 0.2.4.x] 140 Provide diffs between consensuses diff --git a/proposals/215-update-min-consensus-ver.txt b/proposals/215-update-min-consensus-ver.txt new file mode 100644 index 0000000..a38145a --- /dev/null +++ b/proposals/215-update-min-consensus-ver.txt @@ -0,0 +1,94 @@ +Filename: 215-update-min-consensus-ver.txt +Title: Let the minimum consensus method change with time +Author: Nick Mathewson +Created: 15 Nov 2012 +Status: Open + + +0. Overview + + 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 + evolves. + +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 + choose. + + 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. + +2. Design + + 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 + series. + + For flexibility, it might make sense to choose a slightly older + method, if falling back to that method wouldn't cause security + problems. + + + 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 + signatures. + + 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. + +4. Alternatives + + 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 + changing rapidly. + + 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. + +