[tor-dev] Notes on Donncha's Summer of Privacy project about scaling hidden services

[Donncha O'Cearbhaill]

Hi all,

On 12/05/15 15:55, Nick Mathewson wrote:
> 
> 1. Getting the introduction points to the management service
> 
> * Synchonization, and push vs pull.
> 
>   I think we've started to get statistics on the average longevity of
> a busy introduction point.  If the answer is "they change fairly
> often" then we should look at the expected failure rate for trying a
> random introduction point at any given time, given a periodic polling
> interval.  And if *that's* high, we should look for ways to ensure
> that the management service learns about changes in introduction
> points as soon as those changes occur.
> 
>   One possibility here would be to have the management service keep a
> connection open to each of the onion services.  Alternatively, the
> management service could have a hidden service of its own,

Introduction point churn for average onion services seems to be
relatively slow (>10 hours). However services which are heavily used or
under DoS attack can change introduction points very rapidly as they IP
circuits reach the introduction count limits. As such polling from the
HSDirs may not be sufficient for the high load onion services.

There is also a potential issue if the management service includes
expired introduction points from an out-of-date descriptor which was
fetched because of HSDir churn . There is no simple way for the
management service to determine if the descriptor it has fetched is
fresh or not besides the imprecise descriptor timestamp.

A push or pull descriptor transfer mechanism seems to like it would be
the most reliable option but adds complexity to the design by requiring
extra code to be run on the onion service host. Such a design would also
likely require #14846 to be implemented. I'll think about the security
risks of a pull or a push mechanism.

> 
> 2. Future-proofing for proposal 224 (rend-spec-ng.txt)
> 
>  Stealth authorization should no longer be needed in this case;
> anybody who doesn't know the onion address of a prop224 hidden service
> won't be able to find or decrypt its descriptor.
> 
>  But proposal 224 does require that the onion key be cross-certified
> by the introduction point keys.  For that to work, we will need
> support on the onion-service side.  They won't need the master private
> key; only the public key.
> 
>  We need to make sure that as much of this as possible works with the
> offline-private-keys design from proposal 224 as well.
> 
>   Proposal 224 does not yet describe how to make the controller
> commands and events here work for prop-224 hidden services.  We should
> figure out what the requirements are there at some point.

I'll review prop 224 again and keep it in mind during the development.

> 
>  3. Introduction point collision
> 
>  Sometimes two different onion services might wind up picking some
> introduction points in common.  Should we care?
> 
> 4. How many introduction points to expose?
> 
>   It's not clear to me what the ideal number of introduction points is
> to put in each master service descriptor.  All of them?  Two from each
> node?  All possibilities here seem to have some risks.

I'm unsure yet. The naive approach would be to just include the maximum
number of introduction points from each onion service instance. I'd be
interested in any arguments for different approaches to choose and
expose introduction points. Is there a major risk in being
distinguishable from a standard onion service?

I look forward to hearing any comments about the proposal. I'm
interested in talking to onion service operators who are running into
scaling issues. Please feel free to get in touch if you have any
experiences or problems you'd like to share.

Regards,
Donncha

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150512/1265e7e0/attachment.sig>