On Wed, Sep 30, 2015 at 05:12:53PM +0200, Tim Wilson-Brown - teor wrote:
Hi All,
Do you know a use case which needs Single Onion Services and NAT punching?
We’re wondering if there are mobile or desktop applications / services that would use a single onion service for the performance benefits, but still need NAT punching. (And don’t need the anonymity of a hidden service.)
Single Onion Services:
- can’t do NAT punching, (they need an ORPort on a publicly accessible IP address),
- locations are easier to discover, and
- have lower latency.
Note that we considered making the single-onion services proposal (Tor Proposal 252) include a NAT punching option. We didn't for a few reasons.
1. Get the proposal out there. We can always add other protocols either as part of the proposal or in a new one.
2. Double-onion services already provide NAT punching. The performance delta of a sesqui-onion service (onion circuit on one side, roughly half an onion circuit on the other) is not as significant as for plain single-onion services and so yet another protocol to design, maintain, keep compatible, be a counter to new design innovations might not be worth it.
3. Most importantly, Tor generally follows the onion routing philosophy of making trade-offs that make more users more secure with an eye to making the most vulnerable or sensitive the norm.
On the one hand this means things like building for interactive circuits w/ relatively low latency. This is in theory less secure than, e.g., mix based remailers against global external observing and partial relay compromising adversaries. But in practice this leads to much larger networks (making it harder to be global) and leads to millions vs. hundreds of users with greater diversity of use motivation and behavior (making the fact of usage less interesting of itself to adversaries). Cf. my "Why I'm Not An Entropist".
On the other hand, we made the circuits use three relays. Most users would most of the time likely be fine with a one-relay circuit. By this I mean that an adversary that actually intends to do something that is harmful to them intentionally or collaterally is likely countered by a one-relay circuit, which would have a significant performance impact. But this would mean that the users who do need and use three-relay circuits would be much more rare and interesting, easy to separate out, etc. Also the relays themselves become more valuable to compromise (or set up your own, or bridge by owning the ISP) to an adversary, which increases threat to the network itself. For these and other reasons the default for tor circuits has three relays.
Now let's apply this worldview to the sesqui-onion NAT punching case. In a world with single-onion services and double-onion services, this is splitting off the double-onion anonymity set rather than the single-onion set, regardless of what Tor Proposal the protocol is in. So, the users that do require the server location protection that double-onion services provide becomes a much smaller fraction making them more likely interesting/worth pursuing/easier to identify/less plausibly able to claim they only wanted to have better circuit authentication/etc. than if the sesqui-onion services were not an equally easy option to set up.
Also, given at best ambiguously user-understood threat environments, and the well-documented tendency to choose in practice performance/ease against hyperbolic discounting of threats for using encryption and other security measures, we can assume that many will opt for the better performing choice of sesqui-onion services when perhaps they should not have. All the more so in the less-easily understood case of onion services vs. plain client-to-public-destination Tor use. Similar also to the one vs. three relay option, pwning relays by any of the means mentioned two paragraphs above makes it more effective to identify onion services in the sesqui-onion case. Thus putting additional threat pressure on the network itself. (I recognize similar things could be said of single vs. double onion services in general. I have some responses there, but I am already going on overly long as usual.)
These to me are counter-arguments to the advantages of a NAT punching sesqui-onion protocol. I don't question the many clear advantages of having such a protocol. But to me the above make it too great a trade-off to develop them for easy deployment. I don't think the answers concerning this trade-off are just obvious. So I encourage continued examples and discussions of their use. But I would like to be convinced that they outweigh the above (and possibly other examples of) trade-offs before I would support their development and promotion.
aloha, Paul