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

[David Goulet]

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.

5) v2 creation will be allowed pass the "v3 Network/Code Maturity" point until
   we phase it out for real from the code. "HiddenServiceVersion 2" will be
   how to do it. I've been convinced actually and mostly the main argument
   that made me tick is "If we don't allow it, some hackish tor or ugly recipe
   will be recommended on the intertubez."

6) We DO NOT want a v3 kill switch or "do not publish descriptor" parameter in
   the consensus. We couldn't see a useful use case apart from "Oh damn that
   HS v3 code is DDoSing relays" which would require a real kill switch for v3
   and not just "do not publish".

   A correct alternative we think is to actually have consensus params that
   tweak the protocol such as "Num intro point default" and "Lifetime
   intropoint default" and such... (there are few of those magic numbers in
   the code) and in case of catastrophic failure, we can tweak the knob that
   is causing the problem. I'll open a ticket about it if no arguable
   objections on this thread.

That's about it!

Please raise concerns on any point here. I personally think it's simple enough
and gives us enough room to transition over time.

Thanks to everyone with your feedbacks btw, really good stuff! More prop224
email will be in an INBOX near you in the coming weeks/months as we have more
points to discuss.

Cheers!
David
-------------- 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/20161205/5d26f0cc/attachment.sig>