Re: [tor-dev] HS v3 client authorization types

[George Kadianakis <desnacked@xxxxxxxxxx>]

George Kadianakis <desnacked@xxxxxxxxxx> writes:

> Suphanat Chunhapanya <haxx.pop@xxxxxxxxx> 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).
>

I thought about this some more and discussed it with haxxpop on IRC. In
the end, I think that perhaps starting with just desc auth and then in
the future implementing intro auth is also an acceptable plan forward.

A few more things to think about:

a) Desc auth uses x25519 keys. They look like this:

      2B6vNPLQkvRaMnuP9jmfdnCEU+dp82vwTRpMleEPjUA=

   Do we want these keys prefixed with some string? So that it doesn't
   look like a random base64 string that could also be confused with an
   ed25519 key (that's used in intro auth), and so that Tor could throw
   warnings if someone tries to use a wrong key (e.g. give the public
   key to Tor instead of the private key). 

b) We might also want to look into XEdDSA and see if we can potentially
   use the same keypair for both intro auth (ed25519) and desc auth (x25519).
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev