[tor-dev] v2 to v3 onion service transition (was: "old style" hidden services after Prop224)

[Ivan Markin]

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