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,