FEATURE IDEA: Hidden Directory Authorities

[Roger Dingledine]

On Mon, Nov 19, 2007 at 12:29:53AM -0800, Kyle Williams wrote:
> I know that Tor has the PrivateDir option, which uses an Onion Router
> to make the request to the DA to retrieve updated cached-* documents.
> However, this option will not
> function without a pre-cached copy of the cached-routers documents
> because it wouldn't know of an Onion Routers to tunnel the request
> through.
> Basically you need a pre-cached copy of cached-routers for PrivateDir
> to work, right?
> (Please correct me if I am wrong here.)

Right.

Actually, the config option is called __AllDirActionsPrivate. The "__"
at the front means that it's a config option that's meant to be settable
by the Tor controller -- it assumes the controller is using an alternate
mechanism for bootstrapping. It also means that when the controller
issues a 'saveconf' command, that config option doesn't get saved.

> So the questions that entered my mind were:
> * Could Directory Authorities use an .onion address instead of an IP
> address if a pre-cached copy of cached-routers was distributed with
> the initial download of Tor?

Yes, in theory this would work.

> * Would this make the Directory Authorities more resistant to digital
> & physical attack?

Yes, against a weak attacker. Against a stronger attacker, my impression
is that hidden services are less secure than normal Tor circuits. This is
because the hidden service stays in one place and makes an ever-growing
pile of hints for the attacker. Entry guards help but don't totally
resolve the issue. But as usual, more research remains. :)

> * Are "guard" nodes[2] the same as "valet" nodes[1]?
> The wording of "guard" nodes [2] sounds very similar to the concept of
> "valet" nodes [1], but I'm not quite sure if these are the same.  Are
> they?

> [1] Making Anonymous Communications
> ( http://www.onion-router.net/Publications/Briefing-2004.pdf )
> [2] Locating Hidden Servers
> ( http://www.onion-router.net/Publications/locating-hidden-servers.pdf )

No, they're different. Btw, for your [1], you should actually be
looking at http://freehaven.net/anonbib/#valet:pet2006

> Since the DAs would be the most logical place for an attacker to DoS
> or attack, I was thinking that it would make sense if the DAs couldn't
> be found physically or by IP.
> To start a network, I was think of using 3 DAs with 8 nodes.  The
> nodes would act as rendezvous points, introduction points, valet/guard
> points, entry, middle, and exit nodes.
> If the DAs .onion information and 8 startup nodes information was
> pre-cached when Tor is download, would that be enough to keep the DA's
> hidden?

You would effectively still be limited by the robustness of those
8 nodes. If you're fine with that, why not make all 8 of them into
directory authorities?

> Now the big question.  What type of attacks would this be prone to?
> After reading [2], it became clear that someone could attack
> Introduction Points to reveal the true location of the hidden service.
>  But the 'valet' (or 'guard'?) node design model would significantly
> help reduce the probability of this attack being successful.

Last I checked, the valet design needed more thinking before I was
convinced it would work well in practice. For one, somebody needs to
take it from the 'research paper' phase to the 'spec proposal' phase.

>  So, if
> the DA's are acting as a hidden service, in theory, Introduction and
> Valet Points wouldn't be able to distinguish regular hidden services
> from the DA's hidden service.
> 
> I know that by hiding the DA's, every downloaded package of Tor would
> have to contain an up-to-date copy of the cached-routers.  Could a
> "cached-onions" file be introduced into the design to make it clear
> which are Onion Routers and which are Hidden Services?

I don't follow.

Also, note that not all "main" directory authorities need to be hidden
service directory authorities, and vice versa.

Hope that helps,
--Roger