> On 6 Dec. 2016, at 08:02, David Goulet <dgou...@ev0ke.net> wrote: > > On 06 Dec (07:53:16), teor wrote: >> >>> On 6 Dec. 2016, at 07:42, David Goulet <dgou...@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. > > You need a consensus anyway to pick your intro point or HSDir but yes the > engineering part here will be that if you ever configured v2 service and you > realize it's v3, we'll rollback all the things. > > I agree with you that it could be confusing and will require some fun > engineering but I think the advantages of having such a thing outweight the > engineering effort. Unfun part will be on the user side as they will think > their service is ready to start but then will have a warning after consensus > download that it's not. > > It also means we need to do key creation _after_ consensus download so we > don't expose the wrong address to the user. > > Fun... Maybe we can do better, not sure :S
I'd much prefer a #define for the default, and we can change it in the next release. That way, we ensure the code gets proper testing in an alpha series. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------ _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev