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