Forking this thread to discuss onion service transition path.
David Goulet:
The question arise now. Someone running a .onion upgrades her tor that supports v3, should we allow v2 to continue running or transition it to v3 or make them both happy together...? We haven't discuss this in depth and thus we need to come to a decision before we end up implementating this (which is _soon_). I personally could think that we probably want to offer a transition path and thus have maybe a torrc option that controls that behavior meaning allowing v2 for which we enable by default at first and then a subsequent Tor release will disable it so the user would have to explicitely set it to continue running v2 .onion and then finally rip off v2 entirely in an other release thus offering a deprecation path.
We can add arbitrary fields into descriptors. So we can build up kinda "aliases". What comes to mind first:
Onion Service Operator Publishes v2 descriptor with v3 cross-certification. Publishes somewhere their v3 address and cross-cert*. v2-only client Uses v2 service. v3-compatible client Takes v3 address from a descriptor for requested v2 address. Makes a connection to v3 address that looks like a connection to v2 for the end user. There should be no v3->v2 downgrade option. One-way ticket. v3-only client Uses v3 service.
Also, there should not be any torrc options, I think. There is no behavior to control so there is no need to make this transition even more sophisticated.
* There should be a simple tool to generate and verify cross-certifications. Like signify(1) from OpenBSD. Or even simpler. Probably something that even built into TBB.
Don't know if such transparent connection thing is secure or not. It seems to be as secure as v2 services. Thoughts?
-- Ivan Markin