Hello, Nick blessed me as a co-proposal editor last night at PETS2010; I've given the following proposal an initial number of 171. The proposal in question will be updated in my git repository until it is accepted into master: https://gitweb.torproject.org/ioerror/tor.git/blob/refs/heads/isolated-streams:/doc/spec/proposals/171-separate-streams-by-port-or-host.txt Here's the proposal in question: Filename: 171-separate-streams-by-port-or-host.txt Title: Separate streams across circuits by destination port or destination host Author: Robert Hogan, Jacob Appelbaum, Damon McCoy Created: 21-Oct-2008 Modified: 22-Jul-2010 Status: Draft Motivation: Streams are currently attached to circuits without regard to their content, destination host, or destination port. We propose two options, IsolateStreamsByPort and IsolateStreamsByHost to change the default behavior. The contents of some streams will always have revealing plain text information; these streams should be treated differently than other streams that may or may not have unencrypted PII content. DNS, with the exception of DNSCurve, is always unencrypted. It is reasonable to assume that other protocols may exist that have a similar issue and may cause user concern. It is also the case that we must balance network load issues and stream privacy. The Tor network will not currently scale to one circuit per connection nor should it anytime soon. Circuits are currently created with a few constraints and are rotated within a reasonable time window. This allows a rogue exit nodes to correlate all streams on a given circuit. Design: We propose two options for isolation of streams that lessen the observability and linkability of the Tor client's traffic. IsolateStreamsByPort will take a list of ports or optionally the keyword 'All' in place of a port list. The use of the keyword 'All' will ensure that all connections attached to streams will be isolated to separate circuits by port number. IsolateStreamsByHost will take a boolean value. When enabled, all connections, regardless of port number will be isolated with separate circuits per host. If this option is enabled, we should ensure that the client has a reasonable number of pre-built circuits to ensure perceived performance. This should also intentionally limit the total number of circuits a client will build to ten circuits to prevent abuse and load on the network. This is a trade-off of performance for anonymity. Tor will issue a warning if a client encounters this limit. Security implications: It is believed that the proposed changes will improve the anonymity for end user stream privacy. The end user will no longer link all of their traffic at a single exit node during a given time window. Specification: The Tor client circuit selection process is not entirely specified. Any client circuit specification must take these changes into account. Compatibility: The proposed changes should not create any compatibility issues. New Tor clients will be able to take advantage of this without any modification to the network. Implementation: It is further proposed that IsolateStreamsByPort will be enabled by default for port 22, 53, and port 80. It is further proposed that IsolateStreamsByHost will be disabled by default. Implementation notes: The implementation of this option may want to consider cases where the same exit node is shared by two or more circuits and IsolateStreamsByPort is in force. Since the purpose of the option is to reduce the opportunity of Exit Nodes to attack traffic from the same source on multiple ports, the implementation may need to ensure that circuits reserved for the exclusive use of given ports do not share the same exit node. Performance and scalability notes: It is further proposed that IsolateStreamsByPort will be enabled by default for all ports after a reasonable assessment is performed. Specifically, we should determine the impact this option has on Tor clients and the Tor network.
Attachment:
signature.asc
Description: OpenPGP digital signature