Notes on Donncha's Summer of Privacy project about scaling hidden services
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
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
participants (2)
-
Donncha O'Cearbhaill -
Nick Mathewson