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

Sun Nov 27 16:24:11 UTC 2016

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 at ev0ke.net> 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...

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 585 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161127/05bdf927/attachment.sig>