On Sun, Nov 27, 2016 at 01:07:02PM -0500, chelsea komlo wrote:
Hi,
Yes, the onion-service-version and the version of the descriptor that tor publishes are now tightly coupled, comparing v2 and v3. However, this may not always be the case and, indeed, was not the case previously. I'm not saying HiddenServiceVersion is not the correct torrc option, but please keep these problems in mind. Also, realize that the current torrc syntax allows multiple versions (so it would allow tor create both a v2 and v3 descriptor, and if this is used for onion service creation, it could create both v2 and v3 rend services).
That's another possible thing we could do but it has some possible UX consequences. Let's say we have a tor version that by default creates both version for a configured HS. You would end up with two addresses for the same service and then the operator broadcast those somehow to their users.
I think the "multiple address window" is something we should try to minimize, and consider how to avoid entirely for future versions if possible, especially if multiple versions could be supported at once (v3, v4, and v5, for example).
As an operator, I would need to publish multiple addresses for the same service, and communicate which address corresponds to which version.
As an end user, I will either need to 1) try different addresses until one succeeds, or 2) know my current version and use this knowledge when selecting which address to use. Sharing addresses could also be difficult (I might try to share a v3 address with my friend, but it doesn't work for them because they are on v2). It might be good to do user testing to see what other edge scenarios come up, what is hard/confusing, etc.
Yeah, this is a usability nightmare, but this is a tradeoff we have by running both versions in parallel on the network. Hopefully the majority of the clients (as David said) will upgrade to a tor version that support v3 very soon after it's stable, but the edge cases are always the hardest.
System tors are potential landmines. Maybe we should consider planning a public push for Debian/Ubuntu users configuring the deb.tp.o apt source *if* they use a system tor. I worry this may confuse some Tor Browser users who use Debian or Ubuntu, so we'd somehow need to be clear that this is only if they installed tor locally.
Maybe it's impossible to avoid this for the v2 to v3 transition, but minimizing this seems like a good thing to do!
This is definitely something we should start thinking about now/soon before we start planning v4. It's easy to do "don't release v4 client support until x% of the relays support it", but we don't have any idea of when x% of clients that run onion services upgrade, and this may be something we want to seed, as well: not only relay support, but service creation/publication support. Maybe this is something the you should consider doing for v3, too. Start releasing tor versions with v3 relay (IntroPoint, HSDir, etc) support before client support, but also release the service-side support early, too. With this services can start upgrading and publishing descriptors months before clients have the functionality needed for using the new v3 addresses. This could reduce the inherent partitioning and it could minimize the thundering herd of services switching from v2 to v3 addresses all at once. But maybe this is something you already discussed, if so then great!
- Matt