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

[s7r]

Hello David,

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?
> 
> Instead of listing all options and going in an endless loop of possibilities,
> I'll outline what we've discussed so far between some of us. In the following,
> "v2" is current hidden service and "v3" is the next generation detailed in
> prop224.
> 
> 1) Once v3 is released, from that point on _no_ v2 service will be allowed to
>    be created by "tor" itself. It will always be possible to do it by hand by
>    creating an RSA key and putting it in the service directory (see 3 below).
> 
>    The reasoning for this is that we really want to phase out as quickly as
>    possible the v2 protocol for privacy and security reasons.
> 

Perfect. Fully agree.

> 2) All the current torrc options will be kept for v3 as they all apply in
>    terms of format. (One exception might be the client authorization.)
> 

Very good. We can add a new torrc option for ed25519 key based
authentication for clients (v3) so the current
HiddenServiceAuthorizeClient (v2) will not break old torrc's until
everyone upgrades.

However, we could just add an auth-type value after
HiddenServiceAuthorizeClient that will only work for v3. For example:

HiddenServiceAuthorizeClient pubkey client-name,client-name,client-name,...

It's obvious where 'pubkey' comes from, but it can be changed to
anything. This way we preserve the option that it's already common for
users (HiddenServiceAuthorizeClient), we maintain compatibility of
torrcs during transition period and also have the same option in the
future when we are fully migrated to v3.

This is perfectly fine, since we do not use any auth method that works
on v2 to v3 (which I am also super happy with). We also don't restrict
ourselves from the possibility to add new auth-types for v3 in the
future, should we need them.

> 3) When tor is loading config for a service:
> 
>    if a v2 key is found that is an RSA key, we treat that service as v2, print
>    a deprecation warning and continue.
> 
>    if a v3 key is found, use v3, all is good.
> 
>    if no key is found, consider a new service and generate v3 (ties to 1
>    above).
> 

Great.

> 4) Over time, extra option might appear and they will be ONLY for v3 unless
>    for force majeur security madness.
> 
>    One of those options that we want to add is this one as offline key will be
>    a reality with v3:
> 
>     "HiddenServiceOfflineKey 1"
> 
>    It will indicate tor to _not_ generate the master identity key and will
>    require the user to put the public key in the HiddenServiceDir.
> 
> Note that with all of the above it will be possible to have one of your
> application on both v2 and v3 address. Here is a snippet as an example:
> 
>     # v2
>     HiddenServiceDir /srv/hs/v2
>     HiddenServicePort 80 localhost:80
> 
>     # v3
>     HiddenServiceDir /srv/hs/v3
>     HiddenServicePort 80 localhost:80
> 
> The important part here is the different directories but the port points to
> the same place.
> 
> Ok here it is. Please comment, improve, or propose! :)
> 
> Cheers!
> David
> 
> [1] https://www.torproject.org/docs/tor-manual.html.en (see HIDDEN SERVICE OPTIONS)
> 

Yes, this looks good to me as well. As for ADD_ONION, I think we should
give the people that use it automatically for other apps a change until
they upgrade to be compatible with v3, so for the transition period as
long as v2 is supported (but not recommended) in the network, ADD_ONION
controller command will create a v2 service, and we add another
controller command: ADD_ONIONV3 that will create v3 services. When v2 is
permanently gone, we make ADD_ONION a synonym to ADD_ONIONV3, remove the
RSA1024/SHA1 code and we're all set.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161124/eb0668cf/attachment.sig>