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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev