[tor-dev] Onion Services and NAT Punching

[Paul Syverson]

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