mirror of
https://github.com/torproject/torspec.git
synced 2025-02-13 04:40:54 +00:00
Update many proposal statuses.
Now I've updated the status of everything in my proposal-status list.
This commit is contained in:
Nick Mathewson
parent
6fd37d2a41
commit
ab9cf8322b
@ -63,7 +63,7 @@ Proposals by number:
|
||||
140 Provide diffs between consensuses [ACCEPTED]
|
||||
141 Download server descriptors on demand [OBSOLETE]
|
||||
142 Combine Introduction and Rendezvous Points [DEAD]
|
||||
143 Improvements of Distributed Storage for Tor Hidden Service Descriptors [OPEN]
|
||||
143 Improvements of Distributed Storage for Tor Hidden Service Descriptors [SUPERSEDED]
|
||||
144 Increase the diversity of circuits by detecting nodes belonging the same provider [OBSOLETE]
|
||||
145 Separate "suitable as a guard" from "suitable as a new guard" [SUPERSEDED]
|
||||
146 Add new flag to reflect long-term stability [SUPERSEDED]
|
||||
@ -95,31 +95,31 @@ Proposals by number:
|
||||
172 GETINFO controller option for circuit information [ACCEPTED]
|
||||
173 GETINFO Option Expansion [ACCEPTED]
|
||||
174 Optimistic Data for Tor: Server Side [CLOSED]
|
||||
175 Automatically promoting Tor clients to nodes [DRAFT]
|
||||
175 Automatically promoting Tor clients to nodes [REJECTED]
|
||||
176 Proposed version-3 link handshake for Tor [CLOSED]
|
||||
177 Abstaining from votes on individual flags [OPEN]
|
||||
178 Require majority of authorities to vote for consensus parameters [CLOSED]
|
||||
179 TLS certificate and parameter normalization [CLOSED]
|
||||
180 Pluggable transports for circumvention [CLOSED]
|
||||
181 Optimistic Data for Tor: Client Side [CLOSED]
|
||||
182 Credit Bucket [DRAFT]
|
||||
182 Credit Bucket [OPEN]
|
||||
183 Refill Intervals [CLOSED]
|
||||
184 Miscellaneous changes for a v3 Tor link protocol [CLOSED]
|
||||
185 Directory caches without DirPort [OPEN]
|
||||
185 Directory caches without DirPort [SUPERSEDED]
|
||||
186 Multiple addresses for one OR or bridge [CLOSED]
|
||||
187 Reserve a cell type to allow client authorization [CLOSED]
|
||||
188 Bridge Guards and other anti-enumeration defenses [OPEN]
|
||||
188 Bridge Guards and other anti-enumeration defenses [ACCEPTED]
|
||||
189 AUTHORIZE and AUTHORIZED cells [OPEN]
|
||||
190 Bridge Client Authorization Based on a Shared Secret [NEEDS-REVISION]
|
||||
191 Bridge Detection Resistance against MITM-capable Adversaries [OPEN]
|
||||
192 Automatically retrieve and store information about bridges [OPEN]
|
||||
193 Safe cookie authentication for Tor controllers [CLOSED]
|
||||
194 Mnemonic .onion URLs [OPEN]
|
||||
194 Mnemonic .onion URLs [SUPERSEDED]
|
||||
195 TLS certificate normalization for Tor 0.2.4.x [DRAFT]
|
||||
196 Extended ORPort and TransportControlPort [OPEN]
|
||||
197 Message-based Inter-Controller IPC Channel [OPEN]
|
||||
196 Extended ORPort and TransportControlPort [FINISHED]
|
||||
197 Message-based Inter-Controller IPC Channel [REJECTED]
|
||||
198 Restore semantics of TLS ClientHello [CLOSED]
|
||||
199 Integration of BridgeFinder and BridgeFinderHelper [OPEN]
|
||||
199 Integration of BridgeFinder and BridgeFinderHelper [OBSOLETE]
|
||||
200 Adding new, extensible CREATE, EXTEND, and related cells [CLOSED]
|
||||
201 Make bridges report statistics on daily v3 network status requests [OPEN]
|
||||
202 Two improved relay encryption protocols for Tor cells [OPEN]
|
||||
@ -139,17 +139,17 @@ Proposals by number:
|
||||
216 Improved circuit-creation key exchange [CLOSED]
|
||||
217 Tor Extended ORPort Authentication [FINISHED]
|
||||
218 Controller events to better understand connection/circuit usage [CLOSED]
|
||||
219 Support for full DNS and DNSSEC resolution in Tor [DRAFT]
|
||||
220 Migrate server identity keys to Ed25519 [OPEN]
|
||||
219 Support for full DNS and DNSSEC resolution in Tor [OPEN]
|
||||
220 Migrate server identity keys to Ed25519 [ACCEPTED]
|
||||
221 Stop using CREATE_FAST [CLOSED]
|
||||
222 Stop sending client timestamps [CLOSED]
|
||||
223 Ace: Improved circuit-creation key exchange [OPEN]
|
||||
223 Ace: Improved circuit-creation key exchange [RESERVE]
|
||||
224 Next-Generation Hidden Services in Tor [DRAFT]
|
||||
225 Strawman proposal: commit-and-reveal shared rng [DRAFT]
|
||||
225 Strawman proposal: commit-and-reveal shared rng [SUPERSEDED]
|
||||
226 "Scalability and Stability Improvements to BridgeDB: Switching to a Distributed Database System and RDBMS" [OPEN]
|
||||
227 Include package fingerprints in consensus documents [CLOSED]
|
||||
228 Cross-certifying identity keys with onion keys [CLOSED]
|
||||
229 Further SOCKS5 extensions [DRAFT]
|
||||
229 Further SOCKS5 extensions [OPEN]
|
||||
230 How to change RSA1024 relay identity keys [DRAFT]
|
||||
231 Migrating authority RSA1024 identity keys [DRAFT]
|
||||
232 Pluggable Transport through SOCKS proxy [FINISHED]
|
||||
@ -158,13 +158,13 @@ Proposals by number:
|
||||
235 Stop assigning (and eventually supporting) the Named flag [FINISHED]
|
||||
236 The move to a single guard node [OPEN]
|
||||
237 All relays are directory servers [OPEN]
|
||||
238 Better hidden service stats from Tor relays [DRAFT]
|
||||
238 Better hidden service stats from Tor relays [CLOSED]
|
||||
239 Consensus Hash Chaining [DRAFT]
|
||||
240 Early signing key revocation for directory authorities [DRAFT]
|
||||
241 Resisting guard-turnover attacks [DRAFT]
|
||||
242 Better performance and usability for the MyFamily option [OPEN]
|
||||
243 Give out HSDir flag only to relays with Stable flag [OPEN]
|
||||
244 Use RFC5705 Key Exporting in our AUTHENTICATE calls [DRAFT]
|
||||
243 Give out HSDir flag only to relays with Stable flag [CLOSED]
|
||||
244 Use RFC5705 Key Exporting in our AUTHENTICATE calls [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]
|
||||
@ -179,21 +179,14 @@ Proposals by number:
|
||||
Proposals by status:
|
||||
|
||||
DRAFT:
|
||||
175 Automatically promoting Tor clients to nodes
|
||||
182 Credit Bucket
|
||||
195 TLS certificate normalization for Tor 0.2.4.x [for 0.2.4.x]
|
||||
203 Avoiding censorship by impersonating an HTTPS server
|
||||
219 Support for full DNS and DNSSEC resolution in Tor [for 0.2.5.x]
|
||||
224 Next-Generation Hidden Services in Tor
|
||||
225 Strawman proposal: commit-and-reveal shared rng
|
||||
229 Further SOCKS5 extensions
|
||||
230 How to change RSA1024 relay identity keys [for 0.2.?]
|
||||
231 Migrating authority RSA1024 identity keys [for 0.2.?]
|
||||
238 Better hidden service stats from Tor relays
|
||||
239 Consensus Hash Chaining
|
||||
240 Early signing key revocation for directory authorities
|
||||
241 Resisting guard-turnover attacks
|
||||
244 Use RFC5705 Key Exporting in our AUTHENTICATE calls
|
||||
245 Deprecating and removing the TAP circuit extension protocol
|
||||
247 Defending Against Guard Discovery Attacks using Vanguards
|
||||
248 Remove all RSA identity keys
|
||||
@ -205,39 +198,35 @@ Proposals by status:
|
||||
NEEDS-REVISION:
|
||||
190 Bridge Client Authorization Based on a Shared Secret
|
||||
OPEN:
|
||||
143 Improvements of Distributed Storage for Tor Hidden Service Descriptors
|
||||
164 Reporting the status of server votes
|
||||
165 Easy migration for voting authority sets
|
||||
168 Reduce default circuit window
|
||||
177 Abstaining from votes on individual flags [for 0.2.4.x]
|
||||
185 Directory caches without DirPort
|
||||
188 Bridge Guards and other anti-enumeration defenses
|
||||
182 Credit Bucket
|
||||
189 AUTHORIZE and AUTHORIZED cells
|
||||
191 Bridge Detection Resistance against MITM-capable Adversaries
|
||||
192 Automatically retrieve and store information about bridges [for 0.2.[45].x]
|
||||
194 Mnemonic .onion URLs
|
||||
196 Extended ORPort and TransportControlPort [for 0.2.4.x]
|
||||
197 Message-based Inter-Controller IPC Channel [for 0.2.4.x]
|
||||
199 Integration of BridgeFinder and BridgeFinderHelper [for 0.2.4.x+]
|
||||
201 Make bridges report statistics on daily v3 network status requests [for 0.2.4.x]
|
||||
202 Two improved relay encryption protocols for Tor cells
|
||||
209 Tuning the Parameters for the Path Bias Defense [for 0.2.4.x+]
|
||||
210 Faster Headless Consensus Bootstrapping [for 0.2.4.x+]
|
||||
212 Increase Acceptable Consensus Age [for 0.2.4.x+]
|
||||
220 Migrate server identity keys to Ed25519 [for 0.2.x.x]
|
||||
223 Ace: Improved circuit-creation key exchange
|
||||
219 Support for full DNS and DNSSEC resolution in Tor [for 0.2.5.x]
|
||||
226 "Scalability and Stability Improvements to BridgeDB: Switching to a Distributed Database System and RDBMS"
|
||||
229 Further SOCKS5 extensions
|
||||
233 Making Tor2Web mode faster
|
||||
234 Adding remittance field to directory specification
|
||||
236 The move to a single guard node
|
||||
237 All relays are directory servers [for 0.2.7.x]
|
||||
242 Better performance and usability for the MyFamily option
|
||||
243 Give out HSDir flag only to relays with Stable flag
|
||||
246 Merging Hidden Service Directories and Introduction Points
|
||||
ACCEPTED:
|
||||
140 Provide diffs between consensuses
|
||||
172 GETINFO controller option for circuit information
|
||||
173 GETINFO Option Expansion
|
||||
188 Bridge Guards and other anti-enumeration defenses
|
||||
220 Migrate server identity keys to Ed25519 [for 0.2.x.x]
|
||||
244 Use RFC5705 Key Exporting in our AUTHENTICATE calls
|
||||
META:
|
||||
000 Index of Tor Proposals
|
||||
001 The Tor Proposal Process
|
||||
@ -251,6 +240,7 @@ Proposals by status:
|
||||
160 Authorities vote for bandwidth offsets in consensus [for 0.2.1.x]
|
||||
161 Computing Bandwidth Adjustments [for 0.2.1.x]
|
||||
162 Publish the consensus in multiple flavors [in 0.2.3.1-alpha]
|
||||
196 Extended ORPort and TransportControlPort [for 0.2.4.x]
|
||||
204 Subdomain support for Hidden Service addresses
|
||||
217 Tor Extended ORPort Authentication [for 0.2.5.x]
|
||||
232 Pluggable Transport through SOCKS proxy [in 0.2.6]
|
||||
@ -313,11 +303,14 @@ Proposals by status:
|
||||
222 Stop sending client timestamps [in 0.2.4.18]
|
||||
227 Include package fingerprints in consensus documents [in 0.2.6.3-alpha]
|
||||
228 Cross-certifying identity keys with onion keys
|
||||
238 Better hidden service stats from Tor relays
|
||||
243 Give out HSDir flag only to relays with Stable flag
|
||||
SUPERSEDED:
|
||||
112 Bring Back Pathlen Coin Weight
|
||||
113 Simplifying directory authority administration
|
||||
118 Advertising multiple ORPorts at once
|
||||
124 Blocking resistant TLS certificate usage
|
||||
143 Improvements of Distributed Storage for Tor Hidden Service Descriptors
|
||||
145 Separate "suitable as a guard" from "suitable as a new guard"
|
||||
146 Add new flag to reflect long-term stability
|
||||
149 Using data from NETINFO cells
|
||||
@ -327,6 +320,9 @@ Proposals by status:
|
||||
163 Detecting whether a connection comes from a client
|
||||
169 Eliminate TLS renegotiation for the Tor connection handshake
|
||||
170 Configuration options regarding circuit building
|
||||
185 Directory caches without DirPort
|
||||
194 Mnemonic .onion URLs
|
||||
225 Strawman proposal: commit-and-reveal shared rng
|
||||
DEAD:
|
||||
100 Tor Unreliable Datagram Extension Proposal
|
||||
115 Two Hop Paths
|
||||
@ -338,14 +334,18 @@ Proposals by status:
|
||||
REJECTED:
|
||||
134 More robust consensus voting with diverse authority sets
|
||||
147 Eliminate the need for v2 directories in generating v3 directories [for 0.2.4.x]
|
||||
175 Automatically promoting Tor clients to nodes
|
||||
197 Message-based Inter-Controller IPC Channel
|
||||
OBSOLETE:
|
||||
127 Relaying dirport requests to Tor download site / website
|
||||
131 Help users to verify they are using Tor
|
||||
132 A Tor Web Service For Verifying Correct Browser Configuration
|
||||
141 Download server descriptors on demand
|
||||
144 Increase the diversity of circuits by detecting nodes belonging the same provider
|
||||
199 Integration of BridgeFinder and BridgeFinderHelper
|
||||
RESERVE:
|
||||
133 Incorporate Unreachable ORs into the Tor Network
|
||||
211 Internal Mapaddress for Tor Configuration Testing [for 0.2.4.x+]
|
||||
223 Ace: Improved circuit-creation key exchange
|
||||
INFORMATIONAL:
|
||||
159 Exit Scanning
|
||||
|
||||
@ -2,7 +2,7 @@ Filename: 143-distributed-storage-improvements.txt
|
||||
Title: Improvements of Distributed Storage for Tor Hidden Service Descriptors
|
||||
Author: Karsten Loesing
|
||||
Created: 28-Jun-2008
|
||||
Status: Open
|
||||
Status: Superseded
|
||||
|
||||
Change history:
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@ Filename: 175-automatic-node-promotion.txt
|
||||
Title: Automatically promoting Tor clients to nodes
|
||||
Author: Steven Murdoch
|
||||
Created: 12-Mar-2010
|
||||
Status: Draft
|
||||
Status: Rejected
|
||||
|
||||
1. Overview
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@ Filename: 182-creditbucket.txt
|
||||
Title: Credit Bucket
|
||||
Author: Florian Tschorsch and Björn Scheuermann
|
||||
Created: 22 Jun 2011
|
||||
Status: Draft
|
||||
Status: Open
|
||||
|
||||
Overview:
|
||||
|
||||
|
||||
@ -2,7 +2,8 @@ Filename: 185-dir-without-dirport.txt
|
||||
Title: Directory caches without DirPort
|
||||
Author: Nick Mathewson
|
||||
Created: 20-Sep-2011
|
||||
Status: Open
|
||||
Status: Superseded
|
||||
Superseded-by: 237
|
||||
|
||||
Overview:
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ Title: Bridge Guards and other anti-enumeration defenses
|
||||
Author: Nick Mathewson, Isis Lovecruft
|
||||
Created: 14 Oct 2011
|
||||
Modified: 10 Sep 2015
|
||||
Status: Open
|
||||
Status: Accepted
|
||||
|
||||
1. Overview
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@ Filename: 194-mnemonic-urls.txt
|
||||
Title: Mnemonic .onion URLs
|
||||
Author: Sai, Alex Fink
|
||||
Created: 29-Feb-2012
|
||||
Status: Open
|
||||
Status: Superseded
|
||||
|
||||
1. Overview
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@ Filename: 196-transport-control-ports.txt
|
||||
Title: Extended ORPort and TransportControlPort
|
||||
Author: George Kadianakis, Nick Mathewson
|
||||
Created: 14 Mar 2012
|
||||
Status: Open
|
||||
Status: Finished
|
||||
Target: 0.2.4.x
|
||||
|
||||
1. Overview
|
||||
|
||||
@ -4,7 +4,7 @@ Authors: Ondrej Mikle
|
||||
Created: 4 February 2012
|
||||
Modified: 2 August 2013
|
||||
Target: 0.2.5.x
|
||||
Status: Draft
|
||||
Status: Open
|
||||
|
||||
0. Overview
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ Title: Migrate server identity keys to Ed25519
|
||||
Authors: Nick Mathewson
|
||||
Created: 12 August 2013
|
||||
Target: 0.2.x.x
|
||||
Status: Open
|
||||
Status: Accepted
|
||||
|
||||
[Note: This is a draft proposal; I've probably made some important
|
||||
mistakes, and there are parts that need more thinking. I'm
|
||||
|
||||
@ -2,7 +2,7 @@ Filename: 223-ace-handshake.txt
|
||||
Title: Ace: Improved circuit-creation key exchange
|
||||
Author: Esfandiar Mohammadi, Aniket Kate, Michael Backes
|
||||
Created: 22-July-2013
|
||||
Status: Open
|
||||
Status: Reserve
|
||||
|
||||
History:
|
||||
|
||||
|
||||
@ -2,7 +2,8 @@ Filename: 225-strawman-shared-rand.txt
|
||||
Title: Strawman proposal: commit-and-reveal shared rng
|
||||
Author: Nick Mathewson
|
||||
Created: 2013-11-29
|
||||
Status: Draft
|
||||
Status: Superseded
|
||||
Superseded-by: 250
|
||||
|
||||
1. Introduction
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@ Filename: 229-further-socks5-extensions.txt
|
||||
Title: Further SOCKS5 extensions
|
||||
Author: Yawning Angel
|
||||
Created: 25-Feb-2014
|
||||
Status: Draft
|
||||
Status: Open
|
||||
|
||||
0. Abstract
|
||||
|
||||
|
||||
@ -4,6 +4,7 @@ Author: Matthew Finkel
|
||||
Created: 29-Jul-2014
|
||||
Status: Open
|
||||
Target: 0.2.7.x
|
||||
Supersedes: 185
|
||||
|
||||
Overview:
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@ Filename: 238-hs-relay-stats.txt
|
||||
Title: Better hidden service stats from Tor relays
|
||||
Author: George Kadianakis, David Goulet, Karsten Loesing, Aaron Johnson
|
||||
Created: 2014-11-17
|
||||
Status: Draft
|
||||
Status: Closed
|
||||
|
||||
0. Motivation
|
||||
|
||||
|
||||
@ -2,7 +2,8 @@ Filename: 243-hsdir-flag-need-stable.txt
|
||||
Title: Give out HSDir flag only to relays with Stable flag
|
||||
Author: George Kadianakis
|
||||
Created: 2015-03-23
|
||||
Status: Open
|
||||
Status: Closed
|
||||
Implemented-in: 0.2.7
|
||||
|
||||
1. Introduction
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@ Filename: 244-use-rfc5705-for-tls-binding.txt
|
||||
Title: Use RFC5705 Key Exporting in our AUTHENTICATE calls
|
||||
Author: Nick Mathewson
|
||||
Created: 2015-05-14
|
||||
Status: Draft
|
||||
Status: Accepted
|
||||
|
||||
1. Proposal
|
||||
|
||||
|
||||
@ -55,20 +55,6 @@ again to remind me!
|
||||
revised the paragraph.
|
||||
|
||||
|
||||
133 Incorporate Unreachable ORs into the Tor Network [RESERVE]
|
||||
|
||||
This proposal had an idea for letting ORs that can only make
|
||||
outgoing connections still relay data usefully in the network.
|
||||
It's something we should keep in mind, and it's a pretty neat
|
||||
idea, but it radically changes the network topology. Anybody
|
||||
who wants to analyze new network topologies should definitely
|
||||
have a look. (5/2011)
|
||||
|
||||
For this I have introduced a new proposal status, "RESERVE". A
|
||||
proposal is "in 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 [ACCEPTED]
|
||||
|
||||
This proposal describes a way to transmit less directory
|
||||
@ -77,28 +63,6 @@ again to remind me!
|
||||
GSoC project last summer; it is still under revision and on target
|
||||
for merge into 0.2.8. (See ticket #13339) (9/2015)
|
||||
|
||||
143 Improvements of Distributed Storage for Tor Hidden Service
|
||||
Descriptors
|
||||
|
||||
Here's a proposal from Karsten about making the hidden
|
||||
service DHT more reliable and secure to use. It could use
|
||||
more discussion and analysis. We should look into it as part
|
||||
of efforts to improve designs for the next generation of
|
||||
hidden services.
|
||||
|
||||
One problem with the analysis here, though, is that it
|
||||
assumes a fixed set of servers that doesn't change. One
|
||||
reason that we upload to N servers at each chosen point in
|
||||
the ring is that the hidden service host and the hidden
|
||||
service client may have different views of which servers
|
||||
exist. We need to re-do the analysis with some fraction of
|
||||
recent consensuses.
|
||||
|
||||
This is probably superseded by proposal 224; we should close it
|
||||
IMO. (2/2014)
|
||||
|
||||
Time to mark this as SUPERSEDED. (9/2015)
|
||||
|
||||
156 Tracking blocked ports on the client side
|
||||
|
||||
This proposal provides a way for clients to learn which ports
|
||||
@ -126,7 +90,6 @@ again to remind me!
|
||||
This is likely also to be relevant for the ideas of proposal 241,
|
||||
and maybe superseded by some version of that proposal. (2/2015)
|
||||
|
||||
-----
|
||||
164 Reporting the status of server votes
|
||||
|
||||
This proposal explains a way for authorities to provide a
|
||||
@ -138,8 +101,6 @@ 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
|
||||
@ -161,28 +122,16 @@ again to remind me!
|
||||
|
||||
Should update Tor-spec, should close this. (9/2015)
|
||||
|
||||
172 GETINFO controller option for circuit information
|
||||
173 GETINFO Option Expansion
|
||||
Actually, wait, did we ever implement this? Ugh. (9/2015)
|
||||
|
||||
172 GETINFO controller option for circuit information [accepted]
|
||||
173 GETINFO Option Expansion [accepted]
|
||||
|
||||
These would help controllers (particularly arm) provide more
|
||||
useful information about a running Tor process. They're
|
||||
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
|
||||
mode" and "relay mode" for "self-test to see if you would be a
|
||||
good relay, and if so become one." It didn't get enough
|
||||
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
|
||||
@ -191,9 +140,6 @@ 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
|
||||
@ -201,26 +147,11 @@ again to remind me!
|
||||
performance, less buffering insanity, and a possible end to
|
||||
double-gating issues. (6/2012)
|
||||
|
||||
185 Directory caches without DirPort
|
||||
|
||||
The old HTTP directory port feature is no longer used by
|
||||
clients and relays under most circumstances. The proposal
|
||||
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
|
||||
@ -232,7 +163,7 @@ again to remind me!
|
||||
Number 190 needs revision, since its protocol isn't actually
|
||||
so great. (11/2013)
|
||||
|
||||
Mark as RESERVE. (9/2015)
|
||||
Mark as RESERVE? (9/2015)
|
||||
|
||||
192 Automatically retrieve and store information about bridges
|
||||
|
||||
@ -243,17 +174,6 @@ again to remind me!
|
||||
|
||||
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
|
||||
human-usable" proposals. This one makes sentences using a
|
||||
fixed map. This kind of approach is likely to obsoleted if
|
||||
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
|
||||
@ -271,17 +191,7 @@ again to remind me!
|
||||
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
|
||||
protocol that give Tor finer control over the behavior of
|
||||
its transports. Much of this is implemented in 0.2.5
|
||||
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)
|
||||
|
||||
---
|
||||
201 Make bridges report statistics on daily v3 network status requests
|
||||
|
||||
Here's a proposal for bridges to better estimate the number of
|
||||
@ -322,16 +232,6 @@ again to remind me!
|
||||
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 [RESERVE]
|
||||
|
||||
Here, the idea is to serve an XML document over HTTP that
|
||||
would let the know when it's using Tor. The XML document
|
||||
would be returned when you make a request over Tor for a
|
||||
magic address in 127.0.0.0/8. I think we need to do
|
||||
_something_to solve this problem, but I'm not thrilled with
|
||||
the idea of having any more magical addresses like this; we
|
||||
got rid of .noconnect for a reason, after all. (9/2015)
|
||||
|
||||
212 Increase Acceptable Consensus Age
|
||||
|
||||
This proposal suggests that we increase the maximum age of a
|
||||
@ -357,36 +257,6 @@ 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
|
||||
|
||||
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
|
||||
if we want to add support for EdDSA over Curve3617 or something?
|
||||
Can we make it easier than this? And it also needs analysis to
|
||||
make sure it enables us to eventually drop RSA1024 keys
|
||||
entirely.
|
||||
|
||||
I've started building this in #12498, though, so we'd better figure
|
||||
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
|
||||
ntor handshake, using the multi-exponentiation optimization, to
|
||||
run a bit faster at an equivalent security level.
|
||||
|
||||
Assuming that more cryptographers like the security proof, and
|
||||
that the ntor handshake winds up being critical-path in profiles
|
||||
as more clients upgrade to 0.2.4 or 0.2.5, this is something we
|
||||
should consider. (12/2013)
|
||||
|
||||
224 Next-Generation Hidden Services in Tor
|
||||
|
||||
This proposal outlines a more or less completely revised version
|
||||
@ -400,22 +270,6 @@ again to remind me!
|
||||
of attention and improvements to get it done right. I hope to
|
||||
implement this over the course of 2015-2016. (2/2015)
|
||||
|
||||
225 Strawman proposal: commit-and-reveal shared rng
|
||||
|
||||
Proposal 224's solutions for bug #8244 require that authorities
|
||||
regularly agree upon a shared random value which none of them
|
||||
could have influenced or predicted in advance. This proposal
|
||||
outlines a simple one that isn't perfect (it's vulnerable to DOS
|
||||
and to limited influence by one or more collaborating hostile
|
||||
authorities), but it's quite simple, and it's meant to start
|
||||
discussion.
|
||||
|
||||
I hope that we never build this, but instead replace it with
|
||||
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
|
||||
|
||||
@ -424,16 +278,6 @@ again to remind me!
|
||||
|
||||
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
|
||||
keys, to prove onion key ownership in the router descriptor.
|
||||
It's not clear that this actually improves security, but it
|
||||
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
|
||||
@ -507,17 +351,6 @@ again to remind me!
|
||||
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,
|
||||
David Goulet, Karsten Loesing, and Aaron Johnson wrote this to
|
||||
describe a mechanism for the tor network to securely produce
|
||||
aggregate hidden service usage statistics without exposing
|
||||
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
|
||||
@ -552,17 +385,13 @@ again to remind me!
|
||||
right, might lead clients to kick themselves off the network out of
|
||||
paranoia. So, this proposal could use more analysis. (2/2015)
|
||||
|
||||
|
||||
TAKE ANOTHER LOOK AT THESE:
|
||||
|
||||
242 Better performance and usability for the MyFamily option [OPEN]
|
||||
243 Give out HSDir flag only to relays with Stable flag [OPEN]
|
||||
|
||||
(I think we impleented this one! Mark as FINISHED?)
|
||||
|
||||
244 Use RFC5705 Key Exporting in our AUTHENTICATE calls [DRAFT]
|
||||
|
||||
(Mark as ACCEPTED?)
|
||||
Describes a mechanism for using a new ed25519 signature type to
|
||||
reduce the complexity of adding nodes to a family and the size of
|
||||
family lines. (9/2015)
|
||||
|
||||
245 Deprecating and removing the TAP circuit extension protocol [DRAFT]
|
||||
246 Merging Hidden Service Directories and Introduction Points [OPEN]
|
||||
@ -574,11 +403,3 @@ TAKE ANOTHER LOOK AT THESE:
|
||||
252 Single Onion Services [DRAFT]
|
||||
253 Out of Band Circuit HMACs [DRAFT]
|
||||
|
||||
|
||||
Since last time:
|
||||
|
||||
Proposal 197 has been marked as rejected.
|
||||
|
||||
Proposal 199 is now obsolete.
|
||||
|
||||
Proposal 253 is new.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user