NAT-punching in single-onion services seems to me to be a clear functionality improvement with an unclear effect on security.
The NAT-punching protocol that we settled on at the dev meeting was: 1. The single-onion service (SOS) maintains a direct connection to an IP. 2. A client does an HSDir lookup 3. A client simultaneously creates circuits to the IP and an RP of its choosing. 4. The client sends a connection request to the SOS via the IP, indicating the desired RP. 5. The SOS creates a direct connection to the RP, completing the connection. This makes the connection indistinguishable from an HS connection to the client’s guards and middles, except for the end-to-end latency of the RP circuit. The IP and RP can identify the SOS, which they can already do with a non-NAT SOS. So all we’ve done is make SOS clients look like HS clients instead. In fact, I like this so much that I would even argue to make all SOSes at least mimic this rendezvous behavior (which is easy to do even if they don’t want to maintain an IP connection). With this understanding, it is clear that your arguments only work to argue that SOSes in general are not a good idea. Which is a fine enough argument. I think it’s a reasonable hope that new services are attracted to Tor as SOSes instead of being “converted” from HSes. Also,I see SOSes as the next step towards replacing insecure Internet protocols. They should be seen as a replacement for exit traffic in general and not a competitor to hidden services. And given that SOSes share 3-hop client circuits with exit circuits, perhaps we should try and make those two cases indistinguishable. It doesn’t seem impossible, although it probably requires adding some dummy steps to exit connections. Best, Aaron _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
