torproject/torspec
1
0
Fork 0
mirror of https://github.com/torproject/torspec.git synced 2024-11-23 09:49:45 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

cleanup proposals as i read them

Browse Source
This commit is contained in:
Roger Dingledine 2011-02-25 13:33:21 -05:00
parent f9ce33d250
commit 13bd8dd35c
5 changed files with 50 additions and 43 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
proposals/168-reduce-circwindow.txt
View File

@ -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.

15
proposals/169-eliminating-renegotiation.txt
View File

@ -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.

52
proposals/173-getinfo-option-expansion.txt
View File

@ -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).

4
proposals/175-automatic-node-promotion.txt
View File

@ -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

20
proposals/ideas/xxx-pluggable-transport.txt
View File

@ -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.