On 27 Nov (00:44:39), Matthew Finkel wrote:
On Sat, Nov 26, 2016 at 09:25:44PM +1100, teor wrote:
On 26 Nov. 2016, at 02:25, David Goulet dgoulet@ev0ke.net wrote:
- It also means we create an option that will get deprecated once v2 is
phased out so we are adding a "temporary" option for users to "keep creating v2 addresses" but then will be useless and we'll deprecate and get a whole lot confusing if for instance v4 or v5 happens in the next years for X reasons (unlikely but not impossible).
Not if we use the existing HiddenServiceVersion option for this.
Here are the use cases for this option:
- a developer wants to test that their software works with V3 onion services,
before the default is changed,
- a user wants to run their old software with V2 onion services, after the
default is changed.
Running v2 onion is fine, it's creating v2 onion that I don't want the user to control when that tor supports v3.
But what if I have a tor client that only supports v2 onion services, (because it has not been updated yet, or is not maintained,) and I want to use it with a version of tor that only supports v3 onion services? (because it has other security fixes I want)
Ok, I see your point. If some HS operator has a large client base and they are all v2 and that operator updates to a tor with v3, creates new HS well all the clients can't reach that new service so a "transition" period would be desirable.
To be honest, this is a tough one to answer.
I have a little voice whispering in my head saying "this is a bad idea!".
Similarly, "This is not supported" is the ideal solution for this scenario, but being the realist that I am, *someone* will try this and it should work for them. Specifically, I'm thinking about the Jessie and Wheezy users who are using a system tor (as was mentioned earlier). I'm torn because they are doing it wrong, but at the same time, is it their fault? The various other distros are another nightmare. Luckily most users should be using Tor Browser/Messenger, but that doesn't help the edge cases.
Right, that's is an important point. If we do a switch like such that is we release a tor that only allows v3 service creation, we _need_ to make sure Tor Messenger and Browser and Tor Birdy have been released with a v3 client before that. Else, this partitioning of v2 client vs v3 service won't be fun for anyone...
I agree HiddenServiceVersion is useful for providing this transition, but I'm worried this option maybe more surprising than intended, and the manpage's description would need some changes. Currently, the implementation is only asserts the v2 is set (since 2009), so luckily backwards compatibility is not actually a concern. However, the description says:
A list of rendezvous service descriptor versions to publish for the hidden service.
This isn't what we'd want. This is actually the wrong side of tor from what is being discussed. The purpose of this option would change from the descriptor publication side to being something user-facing. Although this option is not currently useful, I worry about repurposing it for specifying how an onion service should be created.
Wait, the code makes that option specific to a HiddenServiceDir so if that value changes to "3", the configured HS has to be considered to be a v3 or creates it for v3. So I think using it is fine.
So, if we were to switch that value to 3 at once in a tor release, all new HS will be v3. The question would be after that if we also allow "2" as a possible value.
Yes, the onion-service-version and the version of the descriptor that tor publishes are now tightly coupled, comparing v2 and v3. However, this may not always be the case and, indeed, was not the case previously. I'm not saying HiddenServiceVersion is not the correct torrc option, but please keep these problems in mind. Also, realize that the current torrc syntax allows multiple versions (so it would allow tor create both a v2 and v3 descriptor, and if this is used for onion service creation, it could create both v2 and v3 rend services).
That's another possible thing we could do but it has some possible UX consequences. Let's say we have a tor version that by default creates both version for a configured HS. You would end up with two addresses for the same service and then the operator broadcast those somehow to their users.
I have this feeling that it could be more of a mayhem of confusion for clients. The 16 char onion will always work but then clients trying the 52 char onion (because they were told it's MORE secure) might fail not realizing that their client is v2 only... and then we end up with all clients using the v2 address. What will happen at the next tor version which will phase out v2? We end up with the same problem again... old clients and so on.
However, the expectation by then would be that we gave enough time to clients to upgrade but on that I have my doubts. We can make sure that TBB/TM/TB have v3 support by the time we roll out v3, we control that. After that, we rely on distros so let's do this exercise with Debian stable. We won't get v3 client everywhere until _after_ Stretch which has not even been released yet and their freeze is around Febuary in theory making it impossible to have v3 in that release considering the amount of work and pace we are implementing this. Meaning, we'll have to wait another 2 years (2019+) at the very least after that plus the time for people to actually do the OS upgrade...
So all in all, the "client upgrading" transition imo only makes sense if we make sure that TBB/TM/TB supports it and after this is out of our control. Really, v3 is a _security_ upgrade so clients have to upgrade at some point, we can't wait for distros... even if it means more pain for some users. We offer a nice deb.torproject.org alternative for this so users aren't let hanging in the desert.
I would prefer we release at least one version with v3 as the default, but that will still create v2 if asked nicely.
(Alternately, we can tell people how to create v2 manually, or we can tell people to keep their old version of tor and make it create v2.)
Ugh. None of these are good, but releasing a tor version with v3 creation as the default and hiding v2 creation behind a torrc option seems like the best and least astonishing decision. I fully agree with David that this is not ideal and v2 should die sooner than possible. However, I'm not convinced this is realistically the best move.
Ok, we discussed lots of things so far. Very GOOD feedback from everyone on the thread! I think we all realize that we are in a situation that whatever the solution, it won't be the ideal and perfect one!
What I'll do is reboot the thread replying to the original message with few points of what was 1) agreed upon and 2) one or two questions that are left for us to answer so we can move forward here as the implementation is kind of ongoing right now.
Thanks! David
Luckily this isn't my decision, so take my 2 cents however you want.</bikeshed>
- Matt
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev