Make a bunch of notes in proposal-status.txt

1 files changed, 124 insertions, 9 deletions

diff --git a/proposals/proposal-status.txt b/proposals/proposal-status.txt
index f094583..869ef1b 100644
--- a/proposals/proposal-status.txt
+++ b/proposals/proposal-status.txt
@@ -65,6 +65,8 @@ again to remind me!
      Probably, there are better choices when it comes to
      distributing software and updates. (11/2013)
 
+     I say, mark it OBSOLETE. (9/2015)
+
 131  Help users to verify they are using Tor [NEEDS-REVISION]
 
      This one is not a crazy idea, but I marked it as
@@ -72,6 +74,9 @@ again to remind me!
      our current designs. It seems mostly superseded by proposal
      211. (11/2013)
 
+     I say, mark it as OBSOLETE and make a note on proposal 211 to see it for
+     historical information. (9/2015)
+
 132  A Tor Web Service For Verifying Correct Browser Configuration
 
      This proposal was meant to give users a way to see if their
@@ -81,6 +86,8 @@ again to remind me!
      that run webservers on localhost, since they become a target
      for cross-site attacks. (11/2013)
 
+     I say mark as OBSOLETE. (9/2015)
+
 133  Incorporate Unreachable ORs into the Tor Network
 
      This proposal had an idea for letting ORs that can only make
@@ -90,13 +97,20 @@ again to remind me!
      who wants to analyze new network topologies should definitely
      have a look. (5/2011)
 
+     For this I think we should introduce a new proposal status,
+     "RESERVE". A proposal is "on reserve" if we're not currently
+     planning to implement it, but we might someday want to do so if we
+     decide that what it provides is a great idea. (9/2015)
+
 140  Provide diffs between consensuses
 
      This proposal describes a way to transmit less directory
      traffic by sending only differences between consensuses, rather
      than the consensuses themselves.  Daniel Marti implemented this for his
      GSoC project last summer; it is still under revision and on target
-     for merge into 0.2.7.  (See ticket #13339)  (2/2015)
+     for merge into 0.2.8.  (See ticket #13339)  (9/2015)
+
+     This needs code review, and needs to marked as ACCCEPTED. (9/2015)
 
 141  Download server descriptors on demand
 
@@ -110,6 +124,8 @@ again to remind me!
      some difficulties in using in a way compatible with
      it. (6/2012)
 
+     I say mark this as OBSOLETE or RESERVE. (9/2015)
+
 143  Improvements of Distributed Storage for Tor Hidden Service
      Descriptors
 
@@ -130,6 +146,7 @@ again to remind me!
      This is probably superseded by proposal 224; we should close it
      IMO. (2/2014)
 
+     Time to mark this as SUPERSEDED. (9/2015)
 
 144  Increase the diversity of circuits by detecting nodes
      belonging the same provider
@@ -142,6 +159,10 @@ again to remind me!
      did in 2008, particularly in light of the relevant paper(s) by
      Matt Edmann and Paul Syverson. (5/2011)
 
+     Mark as OBSOLETE. The research field has advanced very far since
+     this proposal, and new papers on this topic come out every year.
+     (9/2015)
+
 145  Separate "suitable as a guard" from "suitable as a new guard"
      [NEEDS-RESEARCH]
 
@@ -160,6 +181,8 @@ again to remind me!
      approach for weighting guard node selection probabilities; we
      should probably close this ticket. (2/2015)
 
+     I say, mark as OBSOLETE. (9/2015)
+
 156  Tracking blocked ports on the client side
 
      This proposal provides a way for clients to learn which ports
@@ -192,6 +215,8 @@ again to remind me!
      This is an overview of SoaT, with some ideas for how to integrate
      it into Tor. (5/2011)
 
+     (Mark as HISTORICAL? INFORMATIONAL?) (9/2015)
+
 164  Reporting the status of server votes
 
      This proposal explains a way for authorities to provide a
@@ -203,6 +228,8 @@ again to remind me!
      implement, and would be a fine project for somebody who wants
      to get to know the directory code. (5/2011)
 
+     Mark as RESERVE. (9/2015)
+
 165  Easy migration for voting authority sets
 
      This is a design for how to change the set of authorities without
@@ -222,6 +249,8 @@ again to remind me!
      0.2.1.20?  If so, we should make sure that tor-spec.txt is
      updated and close it. (11/2013)
 
+     Should update Tor-spec, should close this. (9/2015)
+
 172  GETINFO controller option for circuit information
 173  GETINFO Option Expansion
 
@@ -230,6 +259,9 @@ again to remind me!
      accepted and some parts of 173 are even implemented: somebody
      just needs to implement the rest. (5/2011)
 
+     Should mark as ACCEPTED; should open tickets for them; should
+     consider whether they're needed, though. (9/2015)
+
 175  Automatically promoting Tor clients to nodes
 
      Here's Steven's proposal for adding a mode between "client
@@ -238,6 +270,9 @@ again to remind me!
      attention when it was posted to the list; more people should
      review it. (5/2011)
 
+     Mark as REJECTED.  I don't see us doing this any time soon.
+     (9/2015)
+
 177  Abstaining from votes on individual flags
 
      Here's my proposal for letting authorities have opinions about some
@@ -246,6 +281,9 @@ again to remind me!
      right.  With more discussion and review, somebody could/should
      build it, I think. (11/2013)
 
+     Mark as RESERVE. I still love this idea, but nobody else seems
+     to think it's necessary (9/2015)
+
 182  Credit Bucket
 
      This proposal suggests an alternative approach to our current
@@ -260,12 +298,19 @@ again to remind me!
      explains how we can get rid of the requirement that non-bridge
      directories have an open directory port. (6/2012)
 
+     Mark as ACCEPTED, after updating it to match in-progress work for
+     "everybody is a directory", which is ontrack for 0.2.8.  Or maybe
+     that work is closer to 237? (9/2015)
+
 188  Bridge Guards and other anti-enumeration defenses
 
      This proposal suggests some ways to make it harder for a relay
      on the Tor network to enumerate a list of Tor bridges. Worth
      investigating and possibly implementing. (6/2012)
 
+     Update and then mark as ACCEPTED; isis has code for this for 0.2.8.
+     (9/2015)
+
 189  AUTHORIZE and AUTHORIZED cells
 190  Bridge Client Authorization Based on a Shared Secret [NEEDS-REVISION]
 191  Bridge Detection Resistance against MITM-capable Adversaries
@@ -277,6 +322,8 @@ again to remind me!
      Number 190 needs revision, since its protocol isn't actually
      so great. (11/2013)
 
+     Mark as RESERVE. (9/2015)
+
 192  Automatically retrieve and store information about bridges
 
      This proposal gives an enhancement to the bridge information
@@ -284,6 +331,8 @@ again to remind me!
      are able to update what they know about them over time.  Could
      help a lot with bridge churn. (6/2012)
 
+     Mark as RESERVE? Do we still even want this? (9/2015)
+
 194  Mnemonic .onion URLs
 
      Here's one of several competing "let's make .onion URLs
@@ -292,6 +341,9 @@ again to remind me!
      we go ahead with current plans for hidden services that
      would make .onion addresses much longer, though. (11/2013)
 
+     We're not going to do this like this, I think.  Mark as
+     SUPERSEDED. (9/2015)
+
 195  TLS certificate normalization for Tor 0.2.4.x
 
      Here's the followup to proposal 179, containing all the parts
@@ -306,6 +358,9 @@ again to remind me!
      fingerprinting can be helpful for snoops; we should take another
      look at it. (2/2015)
 
+     I think we should take a pass over this, pick the parts we still
+     think are relevant, and call them ACCEPTED. (9/2015)
+
 196  Extended ORPort and TransportControlPort
 
      Here are some remaining pieces of the pluggable transport
@@ -314,6 +369,9 @@ again to remind me!
      now; we should figure out what's left, and whether we want
      to build that. (11/2013)
 
+     I think we should mark this FINISHED.  We're not going to do more
+     than we have now, afaik. (9/2015)
+
 197  Message-based Inter-Controller IPC Channel
 
      This proposal is for an architectural enhancement in Tor
@@ -321,6 +379,9 @@ again to remind me!
      various programs (Vidalia, TorBrowser, etc) that are using
      it. (6/2012)
 
+     Mark as RESERVE or REJECTED.  Nobody's asked for this in a really
+     long time, and I don't want to be dbus. (9/2015)
+
 199  Integration of BridgeFinder and BridgeFinderHelper
 
      Here's a proposal for how Tor can integrate with a client
@@ -328,6 +389,8 @@ again to remind me!
      done on things called "BridgeFinder"; I don't know what the
      status of the current proposal is, though. (11/2013)
 
+     Mark as OBSOLETE? I don't think this is still a thing. (9/2015)
+
 201  Make bridges report statistics on daily v3 network status requests
 
      Here's a proposal for bridges to better estimate the number of
@@ -336,9 +399,11 @@ again to remind me!
 202  Two improved relay encryption protocols for Tor cells
 
      Here's a sketch of the two broad classes of alternatives for
-     improving how relay encryption works. Right now, progress on
-     this proposal is stalled waiting for the ideal wide-block
-     construction to come along the line. (11/2013)
+     improving how relay encryption works. Right now, progress on this
+     proposal is stalled waiting for the ideal wide-block construction
+     to come along the line.  AEZ seems like it might be close to what
+     we need. Other cryptographers are also looking at designs that
+     might be a good match. (9/2015)
 
 203  Avoiding censorship by impersonating an HTTPS server
 
@@ -346,6 +411,8 @@ again to remind me!
      HTTPS server (by *being* an HTTPS server) until the user
      proves they know it's a bridge. (11/2013)
 
+     Didn't we do something like this? (9/2015)
+
 209  Tuning the Parameters for the Path Bias Defense
 
      In this proposal, Mike discusses alternative parameters for
@@ -361,6 +428,9 @@ again to remind me!
      consensus from non-Authority DirSources, but we shouldnt' do
      anything to increase the load on authorities.  (11/2013)
 
+     This needs an update; it's a pretty good idea, and Mike and Roger
+     like it.  It goes will with FallbackDirSource stuff. (9/2015)
+
 211  Internal Mapaddress for Tor Configuration Testing
 
      Here, the idea is to serve an XML document over HTTP that
@@ -371,6 +441,8 @@ again to remind me!
      the idea of having any more magical addresses like this; we
      got rid of .noconnect for a reason, after all. (11/2013)
 
+     Mark as REJECTED. (9/2015)
+
 212  Increase Acceptable Consensus Age
 
      This proposal suggests that we increase the maximum age of a
@@ -381,6 +453,8 @@ again to remind me!
      was some tor-dev discussion on this one that should get
      incorporated into a final, implementable version. (11/2013)
 
+     Mark as ACCEPTED? (9/2015)
+
 219  Support for full DNS and DNSSEC resolution in Tor
 
      Here's a design to allow Tor to support a full range of DNS
@@ -394,8 +468,10 @@ again to remind me!
      done with reasonable confidence, and figure out the client side
      once more servers have upgraded.  (12/2013)
 
+     Mark as NEEDS-REVISION? (9/2015)
+
 220  Migrate server identity keys to Ed25519
-v
+
      This one is a design to migrate server identity keys to
      Ed25519 for improved security margin.  It needs more analysis of
      long-term migration to other signing key types -- what do we do
@@ -408,6 +484,9 @@ v
      out out fairly soon.  Other proposals, like 224, depend on this
      one.  (2/2015)
 
+     Mark as ACCEPTED. Some is implemented in 0.2.7; the rest is
+     in-progress. (9/2015)
+
 223  Ace: Improved circuit-creation key exchange
 
      Here's an interesting one. It proposes a replacement for the
@@ -446,12 +525,16 @@ v
      something better. Some alternatives have already been discussed
      on tor-dev; more work is needed, though. (12/2013)
 
+     Mark as SUPERSEDED by proposal 250. (9/2015)
+
 226  Scalability and Stability Improvements to BridgeDB:
      Switching to a Distributed Database System and RDBMS
 
      This one outlines design and behavior changes for a seriously
      refactored bridgedb.  (2/2014)
 
+     I should find out if Isis has a status update for this. (9/2015)
+
 228  Cross-certifying identity keys with onion keys
 
      This proposal signs each server's identity key with its onion
@@ -460,6 +543,8 @@ v
      fixes an annoying gap in our key authentication.  I have it coded
      up in my #12498 branch, targetting 0.2.7. (2/2015)
 
+     Implemented; should mark as CLOSED. (9/2015)
+
 229  Further SOCKS5 extensions
 
      Here's a nice idea for how we can support a new SOCKS5 protocol
@@ -478,6 +563,9 @@ v
      sure we'll be able to build thee, though: implementating proposal
      220 above seems cleverer to me. (2/2015)
 
+     Proposal 220 is in progress, and will retroactively SUPERSEDE this
+     one. (9/2015)
+
 232  Pluggable Transport through SOCKS proxy [OPEN]
 
      Arturo Filastò wrote this proposal for chaining pluggable
@@ -527,6 +615,9 @@ v
      DirServer.  He has an implementation, possibly for 0.2.6 or 0.2.7,
      in ticket #12538.  (2/2015)
 
+     Compare to proposal 185; it may supersede that one.  Review again
+     and mark as accepted maybe?  (9/2015)
+
 238  Better hidden service stats from Tor relays [DRAFT]
 
      Here's an important one that needs many eyes.  George Kadianakis,
@@ -536,6 +627,8 @@ v
      sensitive intermediate results.  This has an implementation in
      0.2.6 and should probably be marked closed.  (2/2015)
 
+     Indeed, mark as closed. (9/2015)
+
 239  Consensus Hash Chaining [DRAFT]
 
      Here's the start of a good idea that Andrea Shepard wrote up (with
@@ -546,6 +639,9 @@ v
      improvements and had good questions (thanks, Leif and Sebastian G!)
      (2/2015)
 
+     Needs revisions while we still remember what those revisions are.
+     (9/2015)
+
 240  Early signing key revocation for directory authorities [DRAFT]
 
      This one is another Andrea+Nick collaboration about certificate
@@ -554,6 +650,9 @@ v
      circulation as fast as possible.  Peter Palfrader on tor-dev had
      some ideas for making this better. (2/2015)
 
+     Needs revisions while we still remember what those revisions are.
+     (9/2015)
+
 241  Resisting guard-turnover attacks [DRAFT]
 
      I wrote this one with good ideas from Aaron Johnson and Rob
@@ -565,11 +664,27 @@ v
      paranoia. So, this proposal could use more analysis.  (2/2015)
 
 
-Since last time:
+TAKE ANOTHER LOOK AT THESE:
 
-     Proposal 140 and 227 have been implemented and closed.
+242  Better performance and usability for the MyFamily option [OPEN]
+243  Give out HSDir flag only to relays with Stable flag [OPEN]
 
-     Proposal 215 was implemented and closed
+     (I think we impleented this one! Mark as FINISHED?)
 
-     Proposals 230 through 241 are new.
+244  Use RFC5705 Key Exporting in our AUTHENTICATE calls [DRAFT]
+
+     (Mark as ACCEPTED?)
+
+245  Deprecating and removing the TAP circuit extension protocol [DRAFT]
+246  Merging Hidden Service Directories and Introduction Points [OPEN]
+247  Defending Against Guard Discovery Attacks using Vanguards [DRAFT]
+248  Remove all RSA identity keys [DRAFT]
+249  Allow CREATE cells with >505 bytes of handshake data [DRAFT]
+250  Random Number Generation During Tor Voting [DRAFT]
+251  Padding for netflow record resolution reduction [DRAFT]
+252  Single Onion Services [DRAFT]
+
+
+Since last time:
 
+      Proposals 242-252 are new.