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

Fri Nov 25 15:25:05 UTC 2016

On 25 Nov (10:33:35), teor wrote:
> 
> > On 25 Nov. 2016, at 03:40, David Goulet <dgoulet at ev0ke.net> wrote:
> > 
> > On 24 Nov (11:13:06), teor wrote:
> >> 
> >>> On 24 Nov. 2016, at 11:04, Yawning Angel <yawning at schwanenlied.me> wrote:
> >>> 
> >>> On Thu, 24 Nov 2016 01:43:15 +0200
> >>> s7r <s7r at sky-ip.org> wrote:
> >>>> I agree that this would be "the technical way" to do it, but real
> >>>> world usability kind of prevents us to do it this way. The spec for
> >>>> ADD_ONION indeed does not say that v2 hidden services will be
> >>>> supported forever and it clearly SHOULD NOT, but it also doesn't make
> >>>> much sense to abolish it at the first Tor release supporting v3
> >>>> services (because if we make ADD_ONION == v3 (best) this is what we
> >>>> are doing).
> >>> 
> >>> Even I don't think `BEST` should be changed to Ed25519 immediately,
> >>> especially when the code is being stabilized.
> >> 
> >> So I think we should have an option:
> >> 
> >> OnionServiceCreateV3 0|1
> > 
> > Few things why I'm not too keen with this even though it could actually be
> > very useful... I'll outline the potential issues here with such an option but
> > unfortunately I don't have a perfect solution in the end. My main concern is
> > not really an easy or intuitive way for the user to start using v3 service but
> > rather when the users will start using it, the network MUST be ready for it
> > which makes things a bit more complicated to do properly I believe.
> > 
> > Considering a torrc option such as "OnionServiceCreateV3 0|1":
> > 
> > 1) This is extremely non intuitive to any operator even power users. The
> >   concept of "v3" is something that very few people will understand what it's
> >   actually is. Even if we go with "OnionServiceEpicNextMoreSecureGeneration
> >   1", we are creating two classes of onion service that will make things more
> >   confusing for the user with the question of "which one should I use?". Also
> >   see 3 below for more confusion.
> 
> We are already creating two classes of onion service: they have significantly
> different user-visible addresses, client authentication, and Tor version
> requirements.

What I meant by this is I want to avoid to have a world where v2 and v3 can be
created at the same time. I think we want either new v2 or new v3 but not both
for a single tor instance. Of course, the network is diversed, we won't stop
that over night but for a single tor release it's easy.

> 
> This option simply controls which version is created by default when the user
> asks for an onion service.
> 
> But we already have a HiddenServiceVersion option, let's use that, and make
> the default:

Yeah that's a better idea actually. Once the network is ready for v3 that is
we judge that we have enough nodes for HSDir and IP (RP doesn't change), we
release a tor with that value to "3".

> 
> For at least one release:
> * whatever the existing service uses, or
> * 2 for new services (with 3 being an alternative),
> 
> For at least one more release:
> * whatever the existing service uses (with 2 being deprecated),
> * 3 for new services (with 2 being deprecated),
> 
> For at least one more release:
> * whatever the existing service uses (with 2 being deprecated),
> * 3 for new services (with 2 being deprecated, and only able to be created
>   manually),

I really think that we want to _avoid_ the scenario where the user has a
choice to create a service between v2 or v3. I don't see any pros of having a
release that does v2 by default when v3 support is supported by the tor
instance.

If v3 is available in tor, you use it. From my perspective, it's a security
issue and shouldn't be a transition usability issue. v2 has to be considered
"broken" that is less secure and as soon as your tor supports v3, it should be
dumped. We should never give a choice to our users between an insecure
protocol vs a secure one.

I also want us to aim for the smallest possible transition window between v2
and v3 meaning that once v3 is ready, we want that set of descriptors to go up
relatively fast and not having 5 early adopters for months making it obvious
who is who in the network. Giving a choice to the user to create v2 or v3 will
slow that down for an already slow process and will partition it intensely.

> 
> For releases after that:
> * make the default and only version 3.
> 
> Do we support the same service publishing version 2 and version 3
> descriptors?
> 
> Or do we expect people to set up two different services and direct them to
> the same port?

This. Both version will live in parallel so as long as you have a tor that
supports v2 and tor can find a RSA key, this is possible. My original email
gives out an example on how to do such a thing.

> Do we want to keep that option as a list for future use?

If I understand correctly your question, if let's say v4 comes in later on,
the key will have a "version tag" so this is how tor knows what version your
service is and then I propose we do the same, you point your HiddenServiceDir
to the key folder and then you copy that if you want different version.

> 
> Either way, we should document that in the man page.

Yes and I would like also a transition guide for sure! Just the new .onion
showing up in the hostname file, I predict confusion a lot :).

> 
> Since there's a default, most users will never set it, and they will just
> see the default for new services change in a particular release, and then
> another release where old services are deprecated, and then they will be gone
> entirely.

Phasing out v2 will be another problem but I don't forsee this until few years
after v3 ... Maybe we could speed it up but the "Debian stable" factor will
make it harder to do it fast.

> 
> > 2) It also means we create an option that will get deprecated once v2 is
> >   phased out so we are adding a "temporary" option for users to "keep
> >   creating v2 addresses" but then will be useless and we'll deprecate and get
> >   a whole lot confusing if for instance v4 or v5 happens in the next years
> >   for X reasons (unlikely but not impossible).
> 
> Not if we use the existing HiddenServiceVersion option for this.
> 
> Here are the use cases for this option:
> * a developer wants to test that their software works with V3 onion services,
>   before the default is changed,
> * a user wants to run their old software with V2 onion services, after the
>   default is changed.

Running v2 onion is fine, it's creating v2 onion that I don't want the user to
control when that tor supports v3.

> 
> > 3) The current plan so far is to add a consensus parameter that will control
> >   the switch for client and service to start using prop224. And every relay
> >   out there that will run a tor supporting the v3 protocol (HSDir, IP, RP)
> >   will speak the protocol no matter what. So then we can decide when the
> >   network is mature enough for client/service to start talking actively that
> >   protocol.
> > 
> >   That switch will also be an opportunity for us to remove v0 and v1 support
> >   as well from tor making that event "The Big Onion Service Switch" or for
> >   short "The BOSS (tm)" :P.
> > 
> >   HOWEVER, the hard part here is getting that consensus param information
> >   about the state of prop224 _before_ configuring your HS.... it's doable but
> >   will weirdly make a specific tor version bootstrap HS much slower as
> >   they'll have to wait for the consensus to be downloaded.... maybe there is
> >   a better way?
> > 
> > Here is an idea, we could rely on a tor version for enabling the feature
> > instead that is we release client/service support when and only when the
> > network is mature so then there will be no confusion, you run version X, you
> > get v3, period, the network is ready. That is again not ideal as we then delay
> > this important new feature by some unknown chunks of 6 months... but at least
> > we have some assurance that it's ready.
> > 
> > We can ship the code in let's say 031 but make tor only use it in 032 for
> > instance.
> > 
> > …
> 
> I think the consensus parameter is more useful as an emergency on/off
> switch for descriptor publication, not service configuration.

True. Actually, in the long run, once v3 is stable and we feel comfortable
with it, I would like us to phase out that consensus param somehow as a
killswitch in the consensus is something that bothers me :S ... but at first
it could save us from a catastrophe. :)

> 
> If the code exists on the client, a user should always be able to configure a v3
> onion service. Even before the consensus is downloaded. Even if they do not have
> access to the network.

Agree.

> 
> So here's how I'd use the consensus parameter:
> * if the consensus parameter says v3 services are disabled, users can configure
>   a v3 service, but it will warn and refuse to publish its descriptor. 
> * if the consensus parameter says v3 services are enabled, users can configure
>   a v3 service, and it will publish its descriptor.
>   (And we should be able to deprecate v3 at some point in the future.)
> 
> And similarly for v2:
> * if the consensus parameter says v2 services are enabled, users can configure
>   a v2 service, and it will publish its descriptor. 
> * if the consensus parameter says v2 services are deprecated, users can
>   configure a v2 service, and it will warn, and then publish its descriptor.
> * if the consensus parameter says v2 services are disabled, users can configure
>   a v2 service, but it will warn and refuse to publish its descriptor.
>   (And some future Tor version will remove support for creating v2 services,
>    and another version will remove support for loading them.)

I could see a consensus param for publication of v2 which could allow us to
phase out v2 faster than waiting for a Tor release to be broadly used which
takes years.

But I just want to reiterate that my strong opinion on this is that if v3 is
available (let's use HiddenServiceVersion 3), tor should ONLY use that for new
service. Which means it will be controlled by a tor release and that release
could also remove v0 and v1 (The Big Switch :).

> 
> We should also consider how this interacts with the protocol lines in the
> consensus.

Service will pick HSDir/IP based on that. See #20571 for IP. We need to do the
same for HSDir actually. Hopefully, we get all this in 030.

Thanks teor! Great comments!
David

> 
> 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- 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/20161125/c4dc27a5/attachment.sig>