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