Re: Proposal idea: User path configuration

[Roger Dingledine <arma@xxxxxxx>]

On Thu, Mar 04, 2010 at 04:24:30AM +0100, Sebastian Hahn wrote:
>    Users can alter the default behavior for path selection with  
> configuration
>    options. In case of conflicts (excluding and requiring the same node) 
> the
>    "StrictNodes" option is used to determine behaviour. If a nodes is  
> both
>    excluded and required via a configuration option, the exclusion takes
>    preference.

I think we should work out the situations where strictnodes is needed,
and the situations where we want to honor the config option even without
strictnodes 1.

For example, if you set entrynodes or exitnodes, then imo you should get
one of the nodes you specified, or fail if none work. You asked for it,
you get it. Similarly, if you set Excludenodes or excludeexitnodes, I
think that should trump any entrynodes or exitnodes you set. And if you
exclude everything that's possible, then you fail to make a circuit. It's
what you asked for. That's pretty much what I built in 0.2.2.7-alpha
(though I haven't finished the "excluding" part).

The part where StrictNodes should come up is when your Tor wants to
do something that we the Tor designers consider non-dangerous, yet you
still want to exclude the node Tor wants to use. Examples here include:

* Your Tor hidden service wants to reach a rendezvous point that a
client picked, to establish a connection to the client.
* Tor wants to publish its hidden service descriptor to the appropriate
HSDir relay, or fetch a hidden service descriptor from the appropriate
HSDir relay.
* Your Tor relay tries to publish a server descriptor to an authority
that you've excluded.

In short, I suggest that we should come up with a reasonable thing for
EntryNodes, ExitNodes, ExcludeNodes, and ExcludeExitNodes to do, such that
a reasonable user would get the behavior they would expect. And we should
have that be the default behavior (i.e. the behavior when StrictNodes is
0). And for the people who say "omg my Tor made a circuit that reached
this relay that I excluded wtf conspiracy", we let them set StrictNodes
and tell them they get to keep both pieces when their Tor behavior breaks
in some way.

There are still some controversial decisions to be made, though. For
example:

* What if Tor as a client wants to reach an introduction point for
a hidden service that the user asked to visit, but that intro point
is in excludenodes? The complex answer is to avoid the excluded intro
points unless that would exclude all of them, in which case, either fail
if StrictNodes is 1 else choose one like normal. The simpler answer
coding-wise is to ignore ExcludeNodes when choosing which intro point
to contact, and then either fail or allow it depending on the value
of StrictNodes. I'm inclined toward the simpler answer here, because I
don't think you should care whether your Tor reaches some relay at the
end of your circuit, if that's all Tor uses the circuit for.

* If you ExcludeNodes a relay but your Tor wants to ask it for directory
information, do we? I think the answer is no, a) because there's a
plausible client-enumeration attack a reasonable person could to be
trying to avoid by excluding it, and b) because the information should be
available from a different relay. And if you exclude all the authorities
and then fail to bootstrap, that's your own fault.

* How do we handle foo.exit when AllowDotExit is 1 but foo is in
ExcludeNodes or ExcludeExitNodes? The user both asked for it and asked
for not it. We could allow it if StrictNodes is 0, and refuse it if
StrictNodes is 1. I'm inclined to just refuse it in both cases, to make
the code (and spec) simpler.

* If we would _implicitly_ append the .exit because of exit enclaving,
but the exit is excluded, then we definitely shouldn't append it.

What other scenarios have I missed?

>    - If "ExitNodes" is provided, then every request requires an exit  
> node on

More precisely, "then every exit circuit requires"

>    - When any of the *Nodes settings are changed, all circuits are  
> expired
>      immediately, to prevent a situation where a previously built  
> circuit
>      is used even though some of its nodes are now excluded.

Right, we do that as of 0.2.2.7-alpha.

> Compatibility:
>
>    The old Strict*Nodes options are deprecated, and the StrictNodes  
> option is
>    new. Tor users may need to update their configuration file.

In the current (0.2.2.x) behavior, setting any Strict*Nodes is an alias
for setting StrictNodes. That way we don't break torrc files as people
upgrade. (Periodically we run into folks like the Ubuntu people who want
us to promise that if they give a newer version to their existing users,
it won't break existing config files.)

--Roger