Re: [tor-dev] prop224: What should we do with torrc options?

[Matthew Finkel <matthew.finkel@xxxxxxxxx>]

On Sun, Nov 27, 2016 at 11:24:11AM -0500, David Goulet wrote:
> 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@xxxxxxxxx> wrote:
> > > > 
> > > >>> 
> > > >>> 2) 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...

Yeah, luckily that is a much easier transition that can be coordinated. I'm not
very concerned about including tor-0.3.x in Tor {Browser,Messenger,Birdy}.
Personally, I view that as a relatively simple discussion that I hope won't get
much push back.

> 
> > 
> > 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.
> 

Correct, I agree. I don't think I was precise when I said this was on the wrong
side of tor. I was splitting tor in half, the user-facing side included the
parts of tor with which users see and interact, like the onion address. If this
changes then this is a user-facing change that could affect user experience.
The other side of tor is the tor network, and how tor clients connect and
interact with tor relays. Users shouldn't see this side or care how it works.
HiddenServiceVersion was originally used as an option that controls what
format(s) a tor client uses when it publishes a rend descriptor for a specific
onion service. If HiddenServiceVersion is modified so it creates a v2 and/or
v3 onion service, then now it has a user-facing effect and controls whether a
user gets an 16 character address or 52 character. I don't think this is a
problem, but a change like this will need to be well documented and (I think)
explicitly included in the changelog.

> > 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.

Oh yes, I do not believe we want users creating both v2 and v3 addresses. I
only wanted to point out that the current HiddenServiceVersion syntax *allows*
specifying multiple versions.

> 
> 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.

Yep. I don't think we have a better option than that. This is a hard problem
that we've run into many times before (and will likely continue running into).

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



> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev