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

[David Goulet]

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.

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

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.

Thoughts?

David

> 
> Create V3 onion services by default when using HiddenServiceDir and
> ADD_ONION BEST.
> 
> Which defaults to 0 for at least the first release containing the new
> code, and then defaults to 1 for at least one release, and then
> is deprecated.
> 
> > ...
> 
> 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/20161124/4bfa24a6/attachment.sig>