[tor-dev] v2 to v3 onion service transition

[Ivan Markin]

David Goulet:
> The thing that worries me about the approach of:
>     "Publishes somewhere their v3 address and cross-cert*."
> 
> ... is the amount of more traffic and complexity we had to the network for
> such a thing. I for sure don't want Tor to maintain some sorts of registry
> here just for a transition period that ultimately will die. Anyway, Tor
> shouldn't have to provide infrastructure for the actual network to work well.

No-no-no! By saying "somewhere" I meant "manually and out-of-band" (e.g.
on the site itself, via OTR chat, wall paintings etc). There is no
mechanism to notify Tor user (hopefully!) about such change. Tor just
provides a transport and nothing else.

> What if the operator has a torrc option that says "Please use this v2 HS and
> cross certify it with the v3.". Out of my head (just an example):
> 
>     HiddenServiceDir /my/service/one
>     HiddenServicePort ...
>     HiddenServiceLinkedWithV3 1
> 
>     HiddenServiceDir /my/service/two
>     HiddenServicePort ...
>     HiddenServiceLinkedWithV3 0 /* Would be off by default to avoid linkability. */

Personally I'm absolutely against any new torrc options. It's hard to
find this file, edit it, restart tor after (okay-okay I'm biased towards
Control and stateless tor here).
It also introduces
LengthyStingsThatAreTooHardToReadAndWhatIsToSayAboutRemember.

> We should also consider if it's really Tor's job to do this. Maybe it's OK to
> leave this job to the operators to deal with the v2 <-> v3 advertisement by
> themselves?
> 
> My guts tell me that I would like to have v3 tied to v2 as little as possible
> really but I also want current .onion operator to be able to provide maximum
> security for their users _especially_ when a .onion is very difficult to give
> around in some harsh political context.

Agreed. To make clearer what I mean:

I meant a userspace tool (maybe embedded into little-t-tor, TBB for
verification) that takes v2 private key and v3 address and creates
cross-ceritification v2->v3 (a signature):

$ onionxcert /path/to/v2-private-key v3-address.onion
base32-encoded-rsa-signature

Also it takes v3 private key and signs this cross-certification:

$ onionxcert /path/to/v3-private-key base32-encoded-rsa-signature
base32-encoded-cross-cert

Afterwards operator publishes (as described above) this document
1024+64=1536 (~308chars) along with v3 onion address. It could be even
"human-readable" (copypastable) :

llamanymityx4fi3l6x2gyzmtmgxjyqyorj9qsb5r543izcwymle.onion
base32-encoded-cross-cert-2gyzmtmgxjyqyorj9qsb5r543izcwy
mh2gyzmtmgxjyqyorj9qsb5r543izcwyml2gyzmtmgxjyqyorj9qsb5r
543izcwyml2gyzmtmgxjyqyorj9qsb5r543izcwyml2gyzmtmgxjyqyo
rj9qsb5r543izcwyml2gyzmtmgxjyqyorj9qsb5r543izcwyml2gyzmt
mgxjyqyorj9qsb5r543izcwymlml2gyzmtmgxjyqyorj9qsb5r543izc
wymlml2gyzmtmgxjyqyorj9qsb

End user verifies it like this:

$ onionxcert -v2 grapelookcorewwwi -v3
llamanymityx4fi3l6x2gyzmtmgxjyqyorj9qsb5r543izcwymle
base32-encoded-cross-cert
OK.

[Yes, it requires an HSDir fetch to get full RSA key].

Then it can also be included into v2 descriptor if the operator wishes
so. (torrc option? :/ modified private key file?)

After all this stuff happened, we can make a transparent connection over
verified v3 onion service that seems like it's still a v2 address for
the end user. At some point users update their address book and get happy.
We can also perform funny trick of v2 - publish "alias" v2 descriptors
without any intropoints and thus making no v2 service.


Thoughts, comments?

> ... that only informed power user will be able to understand what the
> hell is going on (but that we can maybe fix with good documentation,
> blog post and good practices guide).

It's better not to break. :)

--
Ivan Markin