[tor-dev] Potential projects for SponsorR (Hidden Services)

[John Brooks]

> On Oct 20, 2014, at 7:37 AM, George Kadianakis <desnacked at riseup.net> wrote:
> 
> d) There are various projects that are using HSes these days (TorChat,
>   Pond, GlobaLeaks, Ricochet, etc.). We should think whether we want
>   to support these use cases and how we can make their life easier.
>   For example, Fabio has been asking for a way to spin up HSes using
>   the control port (#5976). What other features do people want from
>   the control port?

I’ve got a half-finished proposal for configuration of HS by controllers. I’ll try to finish it up soon.

I think it’s a compelling option even aside from the use case for Ricochet et al. For example, a HS operator could use a script to interactively decrypt and load his private key, instead of leaving it plainly on the filesystem.

> 
> h) Back to the community again. There have recently appeared a few
>   messaging protocols that are inherently using HSes to provide link
>   layer confidentiality and anonymity [1]. Examples include Pond,
>   Ricochet and TorChat.
> 
>   Some of these applications are creating one or more HSes per user,
>   with the assumption that HSes are something easy to make and there
>   is no problem in having lots of them. People are wondering how well
>   these applications scale and whether they are using the Tor network
>   the right way. See John Brooks' mail for a small analysis:
>   https://moderncrypto.org/mail-archive/messaging/2014/000434.html
> 
>   It might be worth researching these use cases to see how well Tor
>   supports them and how they can be supported better (or whether they
>   are a bad idea entirely).

I think the mail you meant to link was:
https://moderncrypto.org/mail-archive/messaging/2014/000846.html

My intuition is that having a lot of low-usage hidden services isn’t difficult for the network. Introduction circuits aren’t a significant drain on resources, and posting 6 descriptors per hour isn’t a significant amount of traffic. I don’t have a good grasp on how expensive it is for the network to have an open circuit. If my vague assumptions hold, I don’t think it’s an issue to have many clients connected to many hidden services for low-throughput tasks, either.

The largest scalability issue here is checking whether a service is online. A successful hsdesc fetch reaches out to one directory, but an unsuccessful one will contact all six (each with its own new circuit). Stupid software - my own included - polling for connectivity causes a lot of traffic this way. I’d propose less-stupid software before changing tor, but lowering the directory mirrors from 6 to a more reasonable number would help.

It might be worth thinking about what Tor could do to better support that kind of “peer-to-peer” hidden service usage, but I don’t think it’s a scalability issue for now. For now, the bigger problem is in trying to scale to very busy hidden services, e.g. #13287.

> 
> == Opt-in HS indexing service ==
> 
> This seems like a fun project that can be used in various ways in the
> future. Of course, the feature must remain opt-in so that only
> services that want to be public will surface.
> 
> For this project, we could make some sort of 'HS authority' which
> collects HS information (the HS descriptor?) from volunteering
> HSes. It's unclear who will run an HS authority; maybe we can work
> with ahmia so that they integrate it in their infrastructure?

What is the benefit to automatically submitting descriptors, instead of the operator opting in by submitting their .onion address on ahmia’s website?

> 
> If we are more experimental, we can even build a basic petname system
> using the HS authority [2]. Maybe just a "simple" NAME <-> PUBKEY
> database where HSes can register themselves in a FIFO fashion. This
> might cause tons of domain camping and attempts for dirty sybil
> attacks, but it might develop into something useful. Worst case we can
> shut it down and call the experiment done? AFAIK, I2P has been doing
> something similar at https://geti2p.net/en/docs/naming

I think this would become a target for adversaries looking to shut down (or impersonate) a particular hidden service. Don’t give up self-authenticating hostnames easily; being the ‘registrar’ is a lot of risk and responsibility.

> - #8243 	Getting the HSDir flag should require more effort
> - #2715 	Is rephist-calculated uptime the right metric for HSDir assignment?

These could have an interesting effect on scalability. If we dramatically reduce the number of HSDirs, it might change my equation above on the costs of many low-usage hidden services.

> == Epilogue ==
> 
> What useful projects/tickets did I forget here?

rend-spec-ng ;)

> 
> Which tasks from the above we should not do? I just went ahead and
> wrote down all the projects I could think of, with the idea that we
> will filter stuff later.
> 
> Thanks!

Thanks for summarizing all of this!

- John