Re: bridge and bridge authority proposal

[Roger Dingledine <arma@xxxxxxx>]

On Sun, Nov 11, 2007 at 03:54:52PM -0500, Roger Dingledine wrote:
> 1.2. Defining DirPort
> 
>   Bridges need to answer BEGIN_DIR requests, both so they can answer
>   "/server/authority" questions ("what's your descriptor?") and so they
>   can supply their bridge users with cached copies of all the various
>   Tor network information.
> 
>   Right now (0.2.0.11-alpha) we require that bridges turn their DirPort on
>   -- which means both that we answer BEGIN_DIR requests and that we fetch
>   and cache directory information in an aggressive way like other servers.
> 
>   But:
>   a) we don't enforce that DirPort is on, since it's not clear how to
>   detect if the user meant to be a bridge. So it's easy to set up a bridge
>   relay that silently refuses BEGIN_DIR requests and is thus useless.
>   b) We don't actually care if they have an open or reachable DirPort. So
>   at some point we should separate having an open DirPort from answering
>   directory questions. Which leads to:
>   c) We need to investigate if there are any anonymity worries with
>   answering BEGIN_DIR requests when our DirPort is off. If there aren't,
>   we should drop the DirPort requirement.
> 
>   I claim that we don't open any new attacks by answering BEGIN_DIR
>   questions when DirPort is off: it's still a fine question to ask what
>   partitioning attacks there are when you can query a Tor client about
>   its current directory opinions, but these attacks already exist when
>   DirPort is on.
> 
>   We need to answer this issue in 0.2.0.x.

On more thought, I think we should fix this by adding a new config option
that all bridges should set: "BridgeRelay 1"

When this is set, Tor automatically acts like a dir cache, whether or
not DirPort is set, and it automatically answers BEGIN_DIR questions
whether or not DirPort is set.

Being explicit about whether we mean to be a bridge relay will also come
in handy when we want to do other activities that bridges should do,
if any more instances like this come up.

(This still leaves issue "c" above unresolved. We should leave that for
0.2.1.x to solve, but we really ought to resolve it.)

I'll patch the proposal and the code, uhm, soon. :)

--Roger