commit 07ca8670182464f24c587ec68a0dbdeb78dfccc5
Author: Nick Mathewson <nickm(a)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.
+
+