Update status on proposals 198, 205, 207

This commit is contained in:
Nick Mathewson 2012-12-25 23:26:16 -05:00
parent 3a7903c3c8
commit aa1fbf4cb3
4 changed files with 19 additions and 18 deletions

View File

@ -118,16 +118,16 @@ Proposals by number:
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]
198 Restore semantics of TLS ClientHello [ACCEPTED]
198 Restore semantics of TLS ClientHello [FINISHED]
199 Integration of BridgeFinder and BridgeFinderHelper [OPEN]
200 Adding new, extensible CREATE, EXTEND, and related cells [OPEN]
201 Make bridges report statistics on daily v3 network status requests [OPEN]
202 Two improved relay encryption protocols for Tor cells [OPEN]
203 Avoiding censorship by impersonating an HTTPS server [DRAFT]
204 Subdomain support for Hidden Service addresses [OPEN]
205 Remove global client-side DNS caching [OPEN]
205 Remove global client-side DNS caching [CLOSED]
206 Preconfigured directory sources for bootstrapping [CLOSED]
207 Directory guards [OPEN]
207 Directory guards [CLOSED]
208 IPv6 Exits Redux [FINISHED]
209 Tuning the Parameters for the Path Bias Defense [OPEN]
210 Faster Headless Consensus Bootstrapping [OPEN]
@ -179,8 +179,6 @@ Proposals by status:
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
204 Subdomain support for Hidden Service addresses
205 Remove global client-side DNS caching
207 Directory guards [for 0.2.4.x]
209 Tuning the Parameters for the Path Bias Defense [for 0.2.4.x+]
210 Faster Headless Consensus Bootstrapping [for 0.2.4.x+]
211 Internal Mapaddress for Tor Configuration Testing [for 0.2.4.x+]
@ -197,7 +195,6 @@ Proposals by status:
172 GETINFO controller option for circuit information
173 GETINFO Option Expansion
186 Multiple addresses for one OR or bridge [for 0.2.4.x+]
198 Restore semantics of TLS ClientHello [for 0.2.4.x]
META:
000 Index of Tor Proposals
001 The Tor Proposal Process
@ -213,6 +210,7 @@ Proposals by status:
161 Computing Bandwidth Adjustments [for 0.2.1.x]
162 Publish the consensus in multiple flavors [in 0.2.3.1-alpha]
180 Pluggable transports for circumvention [in 0.2.3.x]
198 Restore semantics of TLS ClientHello [for 0.2.4.x]
208 IPv6 Exits Redux [for 0.2.4.x] [in 0.2.4.7-alpha]
CLOSED:
101 Voting on the Tor Directory System [in 0.2.0.x]
@ -254,7 +252,9 @@ Proposals by status:
184 Miscellaneous changes for a v3 Tor link protocol [for 0.2.3.x]
187 Reserve a cell type to allow client authorization [for 0.2.3.x]
193 Safe cookie authentication for Tor controllers
205 Remove global client-side DNS caching [in 0.2.4.7-alpha.]
206 Preconfigured directory sources for bootstrapping [in 0.2.4.7-alpha]
207 Directory guards [for 0.2.4.x]
SUPERSEDED:
112 Bring Back Pathlen Coin Weight
113 Simplifying directory authority administration

View File

@ -2,7 +2,7 @@ Filename: 198-restore-clienthello-semantics.txt
Title: Restore semantics of TLS ClientHello
Author: Nick Mathewson
Created: 19-Mar-2012
Status: Accepted
Status: Finished
Target: 0.2.4.x
Status:

View File

@ -2,9 +2,17 @@ Filename: 205-local-dnscache.txt
Title: Remove global client-side DNS caching
Author: Nick Mathewson
Created: 20 July 2012
Status: Open
Implemented-In: 0.2.4.7-alpha.
Status: Closed
-1. STATUS
In 0.2.4.7-alpha, client-side DNS caching is off by default; there
didn't seem to be much benefit in having per-circuit caches. I'm
leaving the original proposal below in tact for historical reasons.
-Nick
0. Overview
This proposal suggests that, for reasons of security, we move

View File

@ -2,7 +2,7 @@ Filename: 207-directory-guards.txt
Title: Directory guards
Author: Nick Mathewson
Created: 10-Oct-2012
Status: Open
Status: Closed
Target: 0.2.4.x
@ -21,8 +21,8 @@ Proposal:
guards as those nodes are down, clients should also pick a small-ish set
of directory guard nodes, to persist in Tor's state file.
Clients should not pick their own guards as directory guards, or pick
their directory guards as regular guards.
Clients should, as much as possible, use their regular guards as their
directory guards.
When downloading a regular directory object (that is, not a hidden
service descriptor), clients should prefer their directory guards
@ -36,13 +36,6 @@ Proposal:
guards and try them, and then use their directory guards to fetch multiple
descriptors in parallel.
Discussion:
The rule that the set of guards and the set of directory guards need to
be disjoint, and the rule that multiple directory guards need to be
providing descriptors, are both attempts to make it harder for a
single node to capture a route.
Open questions and notes:
What properties does a node need to be a suitable directory guard?