one-hop circuit restriction should not apply to special-purpose routers
At some point (r9735?), code was added to src/or/control.c that prevents controllers from attaching streams to one-hop circuits. The idea seems to be that we can use the cost of forking and maintaining a patch as a lever to prevent people from writing controllers that jeopardize the operational security of routers and the anonymity properties of the Tor network by creating and using one-hop circuits rather than the standard three-hop circuits. It may be, for example, that some users do not actually seek true anonymity but simply reachability through network perspectives afforded by the Tor network, and since anonymity is stronger in numbers, forcing users to contribute to anonymity and decrease the risk to server operators by using full-length paths may be reasonable.
Whether or not we agree that the particular approach of using hardcoded, immutable policy in the Tor client to limit self-determinism on the part of clients is the right way to address the risks posed by one-hop circuit utilization (for example, I think that routers ought to take responsibility for ensuring that they are not allowing exit from one-hop circuits), it remains true that as presently implemented, the sweeping restriction of one-hop circuits for all routers limits the usefulness of Tor as a general-purpose technology for building circuits. In particular, we should allow for controllers, such as Blossom, that create and use single-hop circuits involving routers that are not part of the Tor network.
There are several ways to address the problem while maintaining the approach of using hardcoded restrictions in the client code. The simplest solution is to just have a new configuration parameter that allows the attachment of streams to one-hop circuits. An objection to that approach might be that the abusive controllers will simply set the configuration paramter and carry on. Another solution is to require that we can only exit from one-hop circuits if the (single) router in the circuit has a descriptor whose associated purpose is not general. Again, controllers can set purposes on descriptors, or feed the Tor descriptors via POSTDESCRIPTOR, so controllers could still be abusive, but the overhead would be somewhat greater.
A third solution is to require descriptors to have a special option that indicates to the client that they can be used in one-hop circuits, and have clients object, as they do now for all routers, to attaching streams to one-hop circuits for routers that do not have this option set. That solution seems to eliminate the worry about operational router security, since server operators will not set this bit unless they are willing to take on such risk. If we worry about the impact on anonymity of the network resulting from including such "risky" routers in regular Tor path selection, we can just systematically exclude those.
Tactically, we should do something to allow Blossom to say "yes, I really do mean to use this one-hop circuit." What is the right way to achieve this in the short-term?
[Automatically added by flyspray2trac: Operating System: All]