Re: [tor-dev] prop224: What should we do with torrc options?

[Matthew Finkel <matthew.finkel@xxxxxxxxx>]

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