commit 13bd8dd35c887487033f2b17831c9adc0e0cbf86 Author: Roger Dingledine arma@torproject.org Date: Fri Feb 25 13:33:21 2011 -0500
cleanup proposals as i read them --- proposals/168-reduce-circwindow.txt | 2 +- proposals/169-eliminating-renegotiation.txt | 15 ++++---- proposals/173-getinfo-option-expansion.txt | 52 ++++++++++++++------------- proposals/175-automatic-node-promotion.txt | 4 ++- proposals/ideas/xxx-pluggable-transport.txt | 20 ++++++----- 5 files changed, 50 insertions(+), 43 deletions(-)
diff --git a/proposals/168-reduce-circwindow.txt b/proposals/168-reduce-circwindow.txt index c10cf41..a746286 100644 --- a/proposals/168-reduce-circwindow.txt +++ b/proposals/168-reduce-circwindow.txt @@ -37,7 +37,7 @@ Target: 0.2.2 The median round-trip latency appears to be around 2s, with 25% of the data points taking more than 5s. That's a lot of variance.
- We designed Tor originally with the original goal of maximizing + We designed Tor originally with the goal of maximizing throughput. We figured that would also optimize other network properties like round-trip latency. Looks like we were wrong.
diff --git a/proposals/169-eliminating-renegotiation.txt b/proposals/169-eliminating-renegotiation.txt index 2c90f9c..6311124 100644 --- a/proposals/169-eliminating-renegotiation.txt +++ b/proposals/169-eliminating-renegotiation.txt @@ -31,7 +31,7 @@ Target: 0.2.2 In the current Tor TLS connection handshake protocol ("V2", or "renegotiating"), the parties begin with a single certificate sent from the server (responder) to the client (initiator), and - then renegotiate to a two-certs-from-each-authenticating party. + then renegotiate to a two-certs-from-each-authenticating-party. We made this change to make Tor's handshake look like a browser speaking SSL to a webserver. (See proposal 130, and tor-spec.txt.) To tell whether to use the V1 or V2 handshake, @@ -171,7 +171,7 @@ Target: 0.2.2 On learning the link protocol, the server then sends the client a CERT cell and a NETINFO cell. If the client wants to authenticate to the server, it sends a CERT cell, an AUTHENTICATE - cell, and a NETINFO cell, or it may simply send a NETINFO cell if + cell, and a NETINFO cell; or it may simply send a NETINFO cell if it does not want to authenticate.
The CERT cell describes the keys that a Tor instance is claiming @@ -199,7 +199,7 @@ Target: 0.2.2 where CertType is 1 (meaning "RSA/SHA256") CertPurpose is 1 (meaning "link certificate") PublicKey is the DER encoding of the ASN.1 representation - of the RSA key of the subject of this certificate, + of the RSA key of the subject of this certificate NotBefore is a time in HOURS since January 1, 1970, 00:00 UTC before which this certificate should not be considered valid. @@ -208,7 +208,7 @@ Target: 0.2.2 considered valid. SignerID is the SHA-256 digest of the public key signing this certificate - and Signature is the signature of the all other fields in + and Signature is the signature of all the other fields in this certificate, using SHA256 as described in proposal 158.
@@ -362,12 +362,12 @@ Target: 0.2.2 We need to reserve command numbers for CERT and AUTH cells. I suggest that in link protocol 3 and higher, we reserve command numbers 128..240 for variable-length cells. (241-256 we can hold - for future extensions. + for future extensions.)
5. Efficiency
- This protocol add a round-trip step when the client sends a - VERSIONS cell to the server, and waits for the {VERSIONS, CERT, + This protocol adds a round-trip step when the client sends a + VERSIONS cell to the server and waits for the {VERSIONS, CERT, NETINFO} response in turn. (The server then waits for the client's {NETINFO} or {CERT, AUTHENTICATE, NETINFO} reply, but it would have already been waiting for the client's NETINFO, @@ -402,3 +402,4 @@ Target: 0.2.2 - What should servers that don't have TLS renegotiation do? For now, I think they should just get it. Eventually we can deprecate the V2 handshake as we did with the V1 handshake. + diff --git a/proposals/173-getinfo-option-expansion.txt b/proposals/173-getinfo-option-expansion.txt index 03e18ef..54356c9 100644 --- a/proposals/173-getinfo-option-expansion.txt +++ b/proposals/173-getinfo-option-expansion.txt @@ -7,7 +7,7 @@ Status: Accepted Overview:
Over the course of developing arm there's been numerous hacks and - workarounds to gleam pieces of basic, desirable information about the tor + workarounds to glean pieces of basic, desirable information about the tor process. As per Roger's request I've compiled a list of these pain points to try and improve the control protocol interface.
@@ -15,19 +15,19 @@ Motivation:
The purpose of this proposal is to expose additional process and relay related information that is currently unavailable in a convenient, - dependable, and/or platform independent way. Examples of this are... - + dependable, and/or platform independent way. Examples are: + - The relay's total contributed bandwidth. This is a highly requested piece of information and, based on the following patch from pipe, looks trivial to include. http://www.mail-archive.com/or-talk@freehaven.net/msg13085.html - + - The process ID of the tor process. There is a high degree of guess work in obtaining this. Arm for instance uses pidof, netstat, and ps yet still fails on some platforms, and Orbot recently got a ticket about its own attempt to fetch it with ps: https://trac.torproject.org/projects/tor/ticket/1388 - + This just includes the pieces of missing information I've noticed (suggestions or questions of their usefulness are welcome!).
@@ -39,43 +39,45 @@ Security Implications: Specification:
The following addition would be made to the control-spec's GETINFO section: - + "relay/bw-limit" -- Effective relayed bandwidth limit. - + "relay/burst-limit" -- Effective relayed burst limit. - + "relay/read-total" -- Total bytes relayed (download). - + "relay/write-total" -- Total bytes relayed (upload). - + "relay/flags" -- Space separated listing of flags currently held by the - relay as repored by the currently cached consensus. - + relay as reported by the currently cached consensus. + "process/user" -- Username under which the tor process is running, - providing an empty string if none exists. - + or an empty string if none exists. + [what do we mean 'if none exists'?] + "process/pid" -- Process id belonging to the main tor process, -1 if none exists for the platform. - + "process/uptime" -- Total uptime of the tor process (in seconds). - + "process/uptime-reset" -- Time since last reset (startup, sighup, or RELOAD - signal, in seconds). - + signal, in seconds). [should clarify exactly which events cause an + uptime reset] + "process/descriptors-used" -- Count of file descriptors used. - + "process/descriptor-limit" -- File descriptor limit (getrlimit results). - + "ns/authority" -- Router status info (v2 directory style) for all recognized directory authorities, joined by newlines. - + "state/names" -- A space-separated list of all the keys supported by this version of Tor's state. - + "state/val/<key>" -- Provides the current state value belonging to the given key. If undefined, this provides the key's default value. - - "status/ports-seen" -- A summary of which ports we've seen connections + + "status/ports-seen" -- A summary of which ports we've seen connections' circuits connect to recently, formatted the same as the EXITS_SEEN status event described in Section 4.1.XX. This GETINFO option is currently available only for exit relays. @@ -90,7 +92,7 @@ Specification: in their "relay" configuration window, to give them a sense of how they're being used (popularity of the various ports they exit to). Currently only exit relays will receive this event. - + TimeStarted is a quoted string indicating when the reported summary counts from (in GMT).
diff --git a/proposals/175-automatic-node-promotion.txt b/proposals/175-automatic-node-promotion.txt index c990b3f..f97cec0 100644 --- a/proposals/175-automatic-node-promotion.txt +++ b/proposals/175-automatic-node-promotion.txt @@ -175,6 +175,8 @@ Status: Draft might as well be a new one with no history. This policy may change once we start allowing the bridge authority to hand out new IP addresses given the fingerprint. + [Perhaps another consensus param? Also, this means we save previous + IP address in our state file, yes? -RD]
3.x Bandwidth measurement
@@ -222,7 +224,7 @@ Status: Draft * Publication of IP address * Blocking from IRC (even for non-exit relays)
- - What feedback should we give to bridge relays, to encourage then + - What feedback should we give to bridge relays, to encourage them e.g. number of recent users (what about reserve bridges)?
- Can clients back-off from doing these tests (yes, we should do diff --git a/proposals/ideas/xxx-pluggable-transport.txt b/proposals/ideas/xxx-pluggable-transport.txt index 53ba9c6..c23ba92 100644 --- a/proposals/ideas/xxx-pluggable-transport.txt +++ b/proposals/ideas/xxx-pluggable-transport.txt @@ -109,13 +109,13 @@ Design overview
To write a new transport protocol, an implementer must provide two pieces: a "Client Proxy" to run at the initiator side, and a "Server - Proxy" to run a the server side. These two pieces may or may not be + Proxy" to run at the server side. These two pieces may or may not be implemented by the same program.
Each client may run any number of Client Proxies. Each one acts like - a SOCKS proxy that accepts accept connections on localhost. Each one + a SOCKS proxy that accepts connections on localhost. Each one runs on a different port, and implements one or more transport - methods. If the protocol has any parameters, they passed from Tor + methods. If the protocol has any parameters, they are passed from Tor inside the regular username/password parts of the SOCKS protocol.
Bridges (and maybe relays) may run any number of Server Proxies: these @@ -147,7 +147,7 @@ Specifications: Client behavior on the TLS connection to match the digest provided in [id-fingerprint]. If any [k=v] items are provided, they are configuration parameters for the proxy: Tor should separate them with - semicolons and put them user and password fields of the request, + semicolons and put them in the user and password fields of the request, splitting them across the fields as necessary. If a key or value value must contain a semicolon or a backslash, it is escaped with a backslash. @@ -174,6 +174,7 @@ Specifications: Client behavior connections. The Tor client only launches one instance of each external program, even if the same executable is listed for more than one method. + [What if the options are different? -RD]
The same program can implement a managed or an external proxy: it just needs to take an argument saying which one to be. @@ -237,8 +238,8 @@ Server proxy behavior
[If we're using the bridge authority/bridgedb system for distributing bridge info, the right place to advertise bridge lines is probably - the extrainfo document. We also need a way to tell the bridge - authority "don't give out a default bridge line for me"] + the extrainfo document. We also need a way to tell bridgedb + "don't give out a default bridge line for me"]
Server behavior
@@ -289,12 +290,12 @@ Appendix: recommendations for transports make it either get a small userbase, or poor auditing.
Think secure: if your code is in a C-like language, and it's hard to - read it and become convinced it's safe then, it's probably not safe. + read it and become convinced it's safe, then it's probably not safe.
Think small: we want to minimize the bytes that a Windows user needs to download for a transport client.
- Specify: if you can't come up with a good explanation + Specify: if you can't come up with a good explanation [XXX]
Avoid security-through-obscurity if possible. Specify.
@@ -309,4 +310,5 @@ Appendix: recommendations for transports Appendix: Raw-traffic transports
This section describes an optional extension to the proposal above. - We are not sure whether it is a good idea. + We are not sure whether it is a good idea. +