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

[Nick Mathewson <nickm@xxxxxxxxxxxxxx>]

Hi!

Here are some notes on Donncha O'Cearbhaill's design proposal at
https://gist.github.com/DonnchaC/03ad5cd0b8ead0ae9e30 .  (David asked
me to write these up in time for them to be useful.)

You'll probably understand what I'm saying here a lot better if you
read the link above. :)


In general I think this is a solid proposal.  Below are a few small
questions and suggestions.


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,

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.

 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.

yrs,
-- 
Nick
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev