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

teor teor2345 at gmail.com
Mon Dec 5 20:53:16 UTC 2016

> On 6 Dec. 2016, at 07:42, David Goulet <dgoulet at ev0ke.net> wrote:
> On 22 Nov (17:36:33), David Goulet wrote:
>> Hi everyone!
>> We are soon at the stage of implementing the service part of proposal 224
>> (next gen. hidden service.). Parent ticket is #20657 but I'll be discussing
>> here ticket #18054.
>> In a nutshell, we need to figure out the interface for the torrc file[1]. We
>> currently have some options to configure an hidden service and the question is
>> now how do we proceed on using those for next version?
> [snip]
> (Please read original email for some initial context.)
> So over the last week, we've mashed up all the things that were said in this
> thread, me and asn discussed it with some arma also on the side!
> I think the following is the best of all the non ideal solutions we can come
> up with. Below is a superb ascii timeline of what we plan to do in terms of
> transition from v2 to v3:
> Our dystopian reality of now.
> (https://youtu.be/NrmMk1Myrxc
> it's not a Black Mirror SO3 trailer)
>        v
>        |             ~Aug '17          ~Dec '17        Unknown date
>        |-----------------|-----------------|----------------|---------->
>                          |                 ^                ^
>                          ^            v3 Network/Code       |
>                 tor stable release       Maturity           |
>                   with v3 support                       No more v2
>                      (0.3.1)
> Ok, might not be my best ascii art work but I hope it will do. In short:
> - With 0.3.1 (scheduled for August 2017, subject to change), we'll have a tor
>  with v3 support BUT v2 will still be the default value for *new* HS.
>  (HiddenServiceVersion option)
> - For a period of ~4 months we estimate, we'll hope that enough of the network
>  has upgraded to support v3 (relay and HSDir support are in 030) and that the
>  code as some sort of maturity that we are confident to switch and make all
>  new HS be v3. This is the "v3 Network/Code Maturity" marker. Note that it
>  could easily go to 2018 for this switch to happen.
> - When the switch happens, there will be, most likely years, a long period of
>  time where v2 will be deprecated and warnings given to users but still used.
>  That "Unknown date" will be the time we will release a tor stable version
>  _without_ v2 support at all. It's quite unknown when we'll be able to do it.
>  Chances are that we'll rely on our HS statistics and metrics for that.
> That being said, here are the conclusions based on this thread and f2f
> discussion considering the above "procedure":
> 1) When v3 is released in a tor stable version, it will NOT be the default
>   version for new service, v2 will until maturity.
> 2) HiddenServiceVersion is used to control which version of the service you
>   want. Starting from the first time v3 is supported, you'll be able to use
>   it but without any guarantee as we'll be entering the "stabilizing period"
>   but it should be usable.
> 3) ADD_ONION "BEST" will map to whatever default value HiddenServiceVersion is
>   with the tor you have.
> 4) In order to avoid relying on a tor stable version release to switch the
>   default version from 2 to 3, we'll use a consensus parameter. Meaning that
>   once we set that param. to v3, HiddenServiceVersion default value will be
>   that value unless explicitely defined in torrc. It will also allow us to
>   rollback to v2 if we see a swarm of badness occuring. To be clear, service
>   already v3 will stay v3 but the default version for creation will simply
>   change.
> ...

This is problematic: we validate and create onion services at torrc
load, before loading the consensus.

Do we plan to do it afterwards?
That seems like it could be really confusing.


Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
xmpp: teor at torproject dot org

More information about the tor-dev mailing list