prop224: Add a consensus param to enable/disable next gen onion service

We need a consensus parameter that controls the deployment of proposal 224 that is next generation onion service.

Lots of code will go in tor without being used at first so this parameter will tell all the tor out there to start using the new generation onion service.

This is especially important before we merge HSDir support (legacy/trac#17238 (moved)) in order for relay to NOT store 224 descriptors while the rest is under development.

I'm thinking OnionService224=0 (or we can omit 224 here and assume "OnionService" is next gen obviously :).

changed milestone to %Tor: 0.3.0.x-final in legacy/trac

added TorCoreTeam201612 in Legacy / Trac actualpoints::0.1 in Legacy / Trac component::core tor/tor in Legacy / Trac milestone::Tor: 0.3.0.x-final in Legacy / Trac owner::dgoulet in Legacy / Trac points::1 in Legacy / Trac priority::high in Legacy / Trac prop224 in Legacy / Trac resolution::implemented in Legacy / Trac review-group-13 in Legacy / Trac reviewer::nickm in Legacy / Trac severity::normal in Legacy / Trac sponsor::R-must in Legacy / Trac status::closed in Legacy / Trac tor-hs in Legacy / Trac type::enhancement in Legacy / Trac labels

Trac:
Status: new to accepted
Parent: N/A to legacy/trac#12424 (moved)

What would be so bad if relays stored prop224 descriptors before the rest of this stuff is deployed?

Also, if we do something like this, it should have a matching tri-state in the configuration: A "1" means "allow", "0" means "forbid", and "auto" means "look at the consensus".

Replying to nickm:

What would be so bad if relays stored prop224 descriptors before the rest of this stuff is deployed?

Hrm, I would say to avoid for Tor to become an "Internet File System"? :) Ok yes, it's already "possible" with current system but adding an extra one might not be necessary. I'm not strongly against actually but this consensus params is needed anyway as we talked about it before to also be the switch for the removal of v0 and v1 from tor code.

It's also a nice safe switch considering the humongeous-ness of this to turn it off in the early days if we happen to do something really bad? A bit like the same we did with shared random, a way for dirauth to turn it off.

I'm open here, if we are confident that we can introduce code for prop224 without this switch, no problem with me.

The consensus parameter idea sounds like a plausible mechanism for controlling deployment.

What would the consensus parameter do exactly?

Here are some possible answers:

When disabled, it would block HSDirs from accepting prop224 descriptors. It would block relays from responding to prop224 cells. It would block clients from using prop224 onion addresses.

What else?

I've implemented this in branch ticket17238_029_02 thus now part of the larger ticket legacy/trac#17238 (moved). NextGenOnionServices is the chosen option.

Trac:
Parent: legacy/trac#12424 (moved) to legacy/trac#17238 (moved)
Actualpoints: N/A to 0.1

Review and merge will happen in September.

Trac:
Keywords: TorCoreTeam201608 deleted, TorCoreTeam201609 added

Deferring big/risky-feature things (even the ones I really love!) to 0.3.0. Please argue if I'm wrong.

Trac:
Milestone: Tor: 0.2.9.x-final to Tor: 0.3.0.x-final
Keywords: N/A deleted, nickm-deferred-20161005 added

As discussed in Seattle, the idea here would be to have a consensus parameters only for client and service but not the relay side. If the relay supports a feature, it should use it. This will be comparable to the same technique we used for ntor handshake using UseNTorHandshake=1 at once. We'll be able to start switching client and services on as we see enough of the network supporting correctly prop224.

Patch for this will come after legacy/trac#17238 (moved) is merged.

Trac:
Keywords: nickm-deferred-20161005, TorCoreTeam201609 deleted, TorCoreTeam201610 added

Trac:
Keywords: TorCoreTeam201610 deleted, TorCoreTeam201611 added

Un-parenting from legacy/trac#17238 (moved) that has just been merged so we can close it.

Trac:
Parent: legacy/trac#17238 (moved) to N/A

A bit more context:

https://gitlab.com/dgoulet/tor/merge_requests/10#note_14999936

Alright, I've cleaned up the current EnableOnionServiceV3 consensus param. See bug19899_030_01.

If we merge this, lets close this ticket because when we'll implement the service and client functionalities, by design we'll add a consensus param for them so no need for a ticket to remind us that we have to add some piece of code to a feature.

Trac:
Status: accepted to merge_ready

Trac:
Keywords: N/A deleted, review-group-13 added

Trac:
Reviewer: N/A to nickm

Going to December!

Trac:
Keywords: TorCoreTeam201611 deleted, TorCoreTeam201612 added

I like this but it needs a changes file now. Adding one and merging.

Trac:
Resolution: N/A to implemented
Status: merge_ready to closed

closed

changed time estimate to 8h

added 48m of time spent

moved from legacy/trac#19899 (moved)

added Feature + 1 deleted label and removed 1 deleted label

added 1 deleted label and removed 1 deleted label