[tor-dev] HS v3 client authorization types

[George Kadianakis]

Suphanat Chunhapanya <haxx.pop at gmail.com> writes:

> Hi,
>
> On 04/28/2018 06:19 AM, teor wrote:
>>> Or should we require the service to enable both for all clients?
>>>
>>> If you want to let the service be able to enable one while disable the
>>> other, do you have any opinion on how to configure the torrc?
>> 
>> If someone doesn't understand client auth in detail, and just wants
>> to be more secure, we should give them a single option that enables
>> both kinds of client auth. (Security by default.)
>> 
>> OnionServiceClientAuthentication 1
>> (Default: 0)
>> 
>> If someone knows they only want a particular client auth method,
>> we should give them another option that contains a list of active
>> client auth methods. (Describe what you have, not what you don't
>> have, because negatives confuse humans.)
>> 
>> OnionServiceClientAuthenticationMethods intro
>> (Default: descriptor, intro)
>
>
> Do you have any opinion on specifying the client names in your
> recommendation? and the list of client names in "descriptor" and "intro"
> should be independent.
>
> However, what i am currently think of is that we can use the existing
> format.
>
> HiddenServiceAuthorizeClient auth-type client-name,client-name,...
>
> But instead of allowing only two auth-types "descriptor" and "intro", we
> allow another type called "default" which includes both "descriptor" and
> "intro"
>
> So if I put an option:
> HiddenServiceAuthorizeClient default client-name,client-name,...
>
> It will be equivalent to two lines of:
> HiddenServiceAuthorizeClient descriptor client-name,client-name,...
> HiddenServiceAuthorizeClient intro client-name,client-name,...
>
> And on the client side, if I put an option:
> HidServAuth onion-address default x25519-private-key ed25519-private-key
>
> It will be equivalent to two lines of:
> HidServAuth onion-address descriptor x25519-private-key
> HidServAuth onion-address intro ed25519-private-key
>

In general, I feel like being able to individually enable "intro" or
"descriptor" auth might be a worthwhile approach for advanced use cases
(see end of my email).  However, I can see the following issues:

a) It's gonna be hard to communicate what "intro" or "descriptor" auth
   do when enabled individually, and motivate people to use them. I
   think it might actually confuse most operators, except from the super
   advanced ones.

b) It will be more complicated in terms of engineering. Because we would
   have to support three auth types instead of one. Especially so if we
   try to support the special benefits you mentioned in the top post,
   like "If only intro auth is enabled, we can revoke a client without
   republishing the descriptor".

I think my approach here would be to try to support both auth types by
the time we launch this feature (under the "standard" auth type), and
then in the future as we get more insight on how people use them, we
should start allowing to individually switch them on and off.

---

For reference here is how I see the various auth types:

"desc" auth:
       Encrypts the descriptor using x25519.  Protects against HSDirs
       who know the onion address from snooping into the descriptor and
       learning intro points, etc.

"intro" auth:
       Authentication at the introduction layer. Allows end-to-end
       authentication with the onion service. Allows more fine-grained
       control over authentication. Also allows the service to know
       which client is visiting it (see #4700).

"standard" auth:
       The combination of "desc" auth and "intro" auth. This basically
       provides the same security logic as v2 "basic" auth.  IMO, this
       is what most operators want when they turn on client auth.

And here are use cases for switching the auths individually:

"intro" auth without "desc" auth:
       Like haxxpop said in top post, if we only have intro auth we can
       revoke/add clients without needing to republish our descriptor.

"desc" auth without "intro" auth:
       This might be useful if a use case does not appreciate the
       anti-feature of intro auth where it allows the HS to know which
       client is visiting it at any given time (see #4700).