[tor-commits] [torspec/master] Add proposal 215: Let the minimum consensus method change with time

[nickm@xxxxxxxxxxxxxx]

commit 07ca8670182464f24c587ec68a0dbdeb78dfccc5
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
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.
+
+

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