On 13 Sep (21:45:00), Ivan Markin wrote:
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.
Ok Ok. I'm going to TL;DR; the previous thread here to make sense of what's down there written by Ivan.
It seems everyone agrees on a transition path from v2 to v3. There was a debate about if we should kill v2 after some time in favor of _only_ having v3. Security arguments were raised which was also tied to Tor's mission statement (thx Lunar!). From the maintaining perspective, it does NOT make sense to keep v2 over time as 1) it's broken by design and 2) the security of it is bad (RSA1024 and SHA1 and TAP). The HS subsystem is a very complex one for which we should keep maintaining only if we have confidence that it's safe to be used which fails for v2 because of 1) as for starter. So I personally believe it's Tor's duty to provide a transition path and drop a unsecure protocol else we litterally put user at risk which is bottom line for me unacceptable and supersede any other argument about how it's being used in some stable way (like let's say IoT).
That being said, if someone still doesn't agree, raise your voice with arguments that haven't been heard yet. If you also want to add more arguments in favor of dropping v2, you are welcome to do so! :)
One issue raised here by Ivan is a way to cross-certify v2 -> v3 where a service would like to provide this mechanism for client to confirm they do have the right v3 address for the great-leaking-platform.onion v2 :).
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.
I think there might be one. An operator should have the choice to cross-certify a v2 -> v3 linking the two .onion together. I for instance have lots of .onion that I might not want people to link the v3 to the v2. So I should have a way to tell Tor to leave my v2 alone during the transition period.
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.
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. */
Which adds fields to the v3 descriptor including a v2 signing key? in order to avoid the client to fetch the v2 descriptor. Something I don't like about this is that we introduce a torrc option _and_ descriptor fields that will get obsolete when v2 is dropped... and 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).
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.
Thoughts? Brainstorming time! :)
Cheers! David
- 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 _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev