Opened 2 years ago

Closed 22 months ago

#19899 closed enhancement (implemented)

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

Reported by: dgoulet Owned by: dgoulet
Priority: High Milestone: Tor: 0.3.0.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: prop224, tor-hs, review-group-13, TorCoreTeam201612
Cc: Actual Points: 0.1
Parent ID: Points: 1
Reviewer: nickm Sponsor: SponsorR-must

Description

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 (#17238) 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 :).

Child Tickets

Change History (17)

comment:1 Changed 2 years ago by dgoulet

Parent ID: #12424
Status: newaccepted

comment:2 Changed 2 years ago by nickm

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

comment:3 Changed 2 years ago by nickm

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".

comment:4 in reply to:  2 Changed 2 years ago by dgoulet

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.

comment:5 Changed 2 years ago by asn

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?

comment:6 Changed 2 years ago by dgoulet

Actual Points: 0.1
Parent ID: #12424#17238

I've implemented this in branch ticket17238_029_02 thus now part of the larger ticket #17238. NextGenOnionServices is the chosen option.

comment:7 Changed 2 years ago by dgoulet

Keywords: TorCoreTeam201609 added; TorCoreTeam201608 removed

Review and merge will happen in September.

comment:8 Changed 2 years ago by nickm

Keywords: nickm-deferred-20161005 added
Milestone: Tor: 0.2.9.x-finalTor: 0.3.0.x-final

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

comment:9 Changed 2 years ago by dgoulet

Keywords: TorCoreTeam201610 added; TorCoreTeam201609 nickm-deferred-20161005 removed

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_ #17238 is merged.

comment:10 Changed 2 years ago by dgoulet

Keywords: TorCoreTeam201611 added; TorCoreTeam201610 removed

comment:11 Changed 2 years ago by dgoulet

Parent ID: #17238

Un-parenting from #17238 that has just been merged so we can close it.

comment:13 Changed 2 years ago by dgoulet

Status: acceptedmerge_ready

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.

comment:14 Changed 23 months ago by nickm

Keywords: review-group-13 added

comment:15 Changed 23 months ago by nickm

Reviewer: nickm

comment:16 Changed 22 months ago by dgoulet

Keywords: TorCoreTeam201612 added; TorCoreTeam201611 removed

Going to December!

comment:17 Changed 22 months ago by nickm

Resolution: implemented
Status: merge_readyclosed

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

Note: See TracTickets for help on using tickets.