Keep proposals/proposal-status.txt up to date.

5 files changed, 102 insertions, 3 deletions

diff --git a/proposals/001-process.txt b/proposals/001-process.txt
index 6cddb47..ba65211 100644
--- a/proposals/001-process.txt
+++ b/proposals/001-process.txt
@@ -184,6 +184,9 @@ Proposal status:
       It isn't going to turn into a spec unless somebody copy-and-pastes
       it into a new spec for a new subsystem.
 
+   Obsolete: This proposal was flawed and has been superseded by another
+     proposal. See comments in the document for details.
+
    The editors maintain the correct status of proposals, based on rough
    consensus and their own discretion.
 
diff --git a/proposals/259-guard-selection.txt b/proposals/259-guard-selection.txt
index bb5e81c..30bdcfa 100644
--- a/proposals/259-guard-selection.txt
+++ b/proposals/259-guard-selection.txt
@@ -2,9 +2,10 @@ Filename: 259-guard-selection.txt
 Title: New Guard Selection Behaviour
 Author: Isis Lovecruft, George Kadianakis
 Created: 2015-10-28
-Status: Draft
+Status: Obsolete
 Extends: 241-suspicious-guard-turnover.txt
 
+This proposal was made obsolete by proposal #271.
 
 §1. Overview
 
diff --git a/proposals/260-rend-single-onion.txt b/proposals/260-rend-single-onion.txt
index 48aa794..9777e0a 100644
--- a/proposals/260-rend-single-onion.txt
+++ b/proposals/260-rend-single-onion.txt
@@ -2,7 +2,7 @@ Filename: 260-rend-single-onion.txt
 Title: Rendezvous Single Onion Services
 Author: Tim Wilson-Brown, John Brooks, Aaron Johnson, Rob Jansen, George Kadianakis, Paul Syverson, Roger Dingledine
 Created: 2015-10-17
-Status: Draft
+Status: Finished
 
 1. Overview
 
diff --git a/proposals/268-guard-selection.txt b/proposals/268-guard-selection.txt
index 9277dd8..3417b54 100644
--- a/proposals/268-guard-selection.txt
+++ b/proposals/268-guard-selection.txt
@@ -2,13 +2,15 @@ Filename: 268-guard-selection.txt
 Title: New Guard Selection Behaviour
 Author: Isis Lovecruft, George Kadianakis, [Ola Bini]
 Created: 2015-10-28
-Status: Draft
+Status: Obsolete
 
   (Editorial note: this was origianlly written as a revision of
   proposal 259, but it diverges so substantially that it seemed
   better to assign it a new number for reference, so that we
   aren't always talking about "The old 259" and "the new 259". -NM)
 
+  This proposal has been obsoleted by proposal #271.
+
 §1. Overview
 
   Tor uses entry guards to prevent an attacker who controls some
diff --git a/proposals/proposal-status.txt b/proposals/proposal-status.txt
index dc0b332..105dca4 100644
--- a/proposals/proposal-status.txt
+++ b/proposals/proposal-status.txt
@@ -438,6 +438,82 @@ again to remind me!
      against both website traffic fingerprinting as well as hidden service
      circuit setup fingerprinting. (9/2015)
 
+255  Controller features to allow for load-balancing hidden services [DRAFT]
+
+     Specifies a technique to improve the scalability of hidden services by
+     decoupling the introduction and rendezvous functionality so that they can
+     be performed in separate physical machines.
+
+256  Key revocation for relays and authorities [OPEN]
+
+     Specifies how directory authorities and relays can revoke compromised
+     long-term identity keys.
+
+257  Refactoring authorities and making them more isolated from the net [META]
+
+     Describes a strategy for making directory authorities less vulnerable to
+     DoS by reducing their exposure to the network.
+
+258  Denial-of-service resistance for directory authorities [ACCEPTED]
+
+     Describes heuristics that directory authorities can deploy to reduce the
+     threat of DoS due to large directory connection volumes.
+
+259  New Guard Selection Behaviour [OBSOLETE]
+
+     Specifies an improved guard-picking algorithm that is capable of defending
+     against targetted attacks. The proposal has since been obsoleted by
+     proposal 271.
+
+260  Rendezvous Single Onion Services [FINISHED]
+
+     Specifies a performance optimization for hidden service that do not care
+     about location anonymity, so that they build 1-hop circuits instead of
+     3-hop circuits to reduce communication latency.
+
+261  AEZ for relay cryptography [OPEN]
+
+     Specifies a circuit encryption scheme that is resistant to tagging
+     end-to-end correlation attacks.
+
+262  Re-keying live circuits with new cryptographic material [OPEN]
+
+     Specifies a way to rekey our circuit crypto so that we allow greater
+     amounts of encrypted data through them.
+
+263  Request to change key exchange protocol for handshake v1.2 [OBSOLETE]
+
+     Specifies a quantum-safe key agreement algorithm for Tor circuits. The
+     proposal was supereceded by proposal 269.
+
+264  Putting version numbers on the Tor subprotocols [CLOSED]
+
+     Specifies a way for relays to do versioning using their descriptors. In
+     the past we used the Tor version string for versioning, which is not an
+     elegant approach.
+
+265  Load Balancing with Overhead Parameters [ACCEPTED]
+
+     The proposal provides new load balancing equations for Tor which are
+     capable of taking into account non-standard traffic like padding or
+     directory and hidden service traffic.
+
+266  Removing current obsolete clients from the Tor network [DRAFT]
+
+     Specifies ways to disable outdated and insecure Tor clients.
+
+267  Tor Consensus Transparency [DRAFT]
+
+     Specifies how to apply the certificate transparency approach of TLS to Tor
+     consensus and vote documents, in an attempt to make attacks more easily
+     detectable.
+
+268  New Guard Selection Behaviour [DRAFT]
+
+     Specifies an improved guard-picking algorithm that is capable of defending
+     against targetted attacks. The proposal has since been obsoleted by
+     proposal 271.
+
 269  Transitionally secure hybrid handshakes [DRAFT]
 
      Describes a generalised protocol for composing X25519 key exchanges with
@@ -448,3 +524,20 @@ again to remind me!
      Describes a hybrid handshake based on the ntor handshake and the
      NewHope post-quantum key exchange.  Currently needs revision to
      specify how this proposal depends upon prop#269.
+
+271  Another algorithm for guard selection [OPEN]
+
+     Specifies an improved guard-picking algorithm that is capable of defending
+     against targetted attacks.
+
+272  Listed routers should be Valid, Running, and treated as such [FINISHED]
+
+     This proposal describes a change in how clients understand consensus
+     flags, and how authorities vote on consensuses.
+
+273  Exit relay pinning for web services [DRAFT]
+
+     The proposal specifies a scheme for websites to prevent additional
+     security against malicious exit nodes, by specifying their own set of exit
+     nodes.
+