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

[John Brooks <john.brooks@xxxxxxxxxxxxxxxx>]

> On Oct 20, 2014, at 7:37 AM, George Kadianakis <desnacked@xxxxxxxxxx> 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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev