[tor-dev] v2 to v3 onion service transition
twim at riseup.net
Wed Sep 14 19:26:00 UTC 2016
> 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
> 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
> 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
Also it takes v3 private key and signs this cross-certification:
$ onionxcert /path/to/v3-private-key base32-encoded-rsa-signature
Afterwards operator publishes (as described above) this document
1024+64=1536 (~308chars) along with v3 onion address. It could be even
"human-readable" (copypastable) :
End user verifies it like this:
$ onionxcert -v2 grapelookcorewwwi -v3
[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.
> ... 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. :)
More information about the tor-dev