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

[Suphanat Chunhapanya]

> 
> Actually, we should have a simple format like "ed25519:" instead
> so then in 5 years, if we end up with 10 different authorization method, we
> can just pass "key:value" argument at will to the torrc option.
> 

To be better, I prefer "ed25519:private:"

>>
>> Some more things to do:
>> - Rename "./client_authorized" to "./authorized_clients"?
> 
> +1

+1

>> - What's the "auth-type"? I assume standard.
> 
> We could use "descriptor" even though it won't stay much to a regular user, it
> will at least have a semantic for power users. Because even "standard" for
> regular user will probably mean nothing... ?

+1



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[David Goulet]

On 12 Jul (20:24:54), George Kadianakis wrote:
> David Goulet  writes:
> 
> > On 18 May (19:03:09), George Kadianakis wrote:
> >> Ian Goldberg  writes:
> >> 
> >> > On Thu, May 10, 2018 at 12:20:05AM +0700, Suphanat Chunhapanya wrote:
> >> >> On 05/09/2018 03:50 PM, George Kadianakis wrote:
> >> >> > 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).
> >> >> 
> >> >> This will be a great advantage if we can do that because putting two
> >> >> private keys in the HidServAuth is so frustrating.
> >> >
> >> > The private key for intro auth is used to make a signature (that will be
> >> > different per client), while the private key for desc auth is used to
> >> > decrypt the descriptor (which will be the same for all clients), no?
> >> >
> >> 
> >> Hm. Both intro auth and desc auth keys are different for each client. In
> >> the case of desc auth we do that so that we can revoke a client without
> >> needing to refresh desc auth keys for all other clients.
> >
> > Following yesterday's discussion on IRC with haxxpop and asn, and some more
> > today, I worked on a revised version of the spec:
> >
> > https://gitweb.torproject.org/user/dgoulet/torspec.git/commit/?h=ticket20700_01
> >
> > Probably will be easier to just read the whole thing instead of the diff:
> >
> > https://gitweb.torproject.org/user/dgoulet/torspec.git/tree/rend-spec-v3.txt?h=ticket20700_01#n2279
> >
> > So the idea is that instead of making the HS client/operator have to pass
> > around portions of a file containing private and public keys, it is to
> > logically seperate them so that the operator only deals with one single file
> > when wanting to transmit the keys to a client.
> >
> 
> Thanks for the fixes David.
> 
> Please see last commit of https://github.com/torproject/torspec/pull/24
> for some stuff on top of your branch.
> 
> Some things we need to think about:
> - The ".pubkeys" files are now used internally by Tor, whereas the
>   "./client_cfg_lines" file is the one that the operator is supposed to
>   look at and interact with. Is it easier for the operator to deal with
>   one big file, or with many small files? We should think about that and
>   maybe reverse our choices.

Single file might actually be better for the client_cfg_lines because 1) it is
much easier to shred out of the filesystem, 2) it is also much easier to spot
by the operator that she still has private keys from client(s) instead of
having to look constantly into client_cfg_lines for leftover lines.

> 
>   As an example, how is the operator supposed to know which line in
>   "./client_cfg_lines" is for which client? In my patch above I used
>   # comments to separate lines but that might not be straightforward for
>   people.
> 
> - Assuming that we are not doing intro auth any time soon, I deleted all
>   mentions of ed25519 keys from that side of the spec, in the assumption
>   that we will need to introduce them back the right way if we ever
>   decide to do intro auth. Is this a good idea or not?
> 
>   As an example of the complexity I'm trying to hide, if we keep ed25519
>   in the spec, we need to specify how the HidServAuth line knows whether
>   a key is x25519 or ed25519.

Actually, we should have a simple format like "ed25519:" instead
so then in 5 years, if we end up with 10 different authorization method, we
can just pass "key:value" argument at will to the torrc option.

> 
> - Do we need to define new torrc options for service-side and client-side?

So far, only client side needs a new "HidServAuth".

> 
> Some more things to do:
> - Rename "./client_authorized" to "./authorized_clients"?

+1

> - Rename "./client_cfg_lines" to 

Lets go single file! I actually now prefer single file.

> - What's the "auth-type"? I assume standard.

We could use "descriptor" even though it won't stay much to a regular user, it
will at least have a semantic for power users. Because even "standard" for
regular user will probably mean nothing... ?

David

-- 
fbv5H3G6O9hLu6Txl6sNIg/unJ95a7iOi43Afzw8ROs=


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[George Kadianakis]

David Goulet  writes:

> On 18 May (19:03:09), George Kadianakis wrote:
>> Ian Goldberg  writes:
>> 
>> > On Thu, May 10, 2018 at 12:20:05AM +0700, Suphanat Chunhapanya wrote:
>> >> On 05/09/2018 03:50 PM, George Kadianakis wrote:
>> >> > 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).
>> >> 
>> >> This will be a great advantage if we can do that because putting two
>> >> private keys in the HidServAuth is so frustrating.
>> >
>> > The private key for intro auth is used to make a signature (that will be
>> > different per client), while the private key for desc auth is used to
>> > decrypt the descriptor (which will be the same for all clients), no?
>> >
>> 
>> Hm. Both intro auth and desc auth keys are different for each client. In
>> the case of desc auth we do that so that we can revoke a client without
>> needing to refresh desc auth keys for all other clients.
>
> Following yesterday's discussion on IRC with haxxpop and asn, and some more
> today, I worked on a revised version of the spec:
>
> https://gitweb.torproject.org/user/dgoulet/torspec.git/commit/?h=ticket20700_01
>
> Probably will be easier to just read the whole thing instead of the diff:
>
> https://gitweb.torproject.org/user/dgoulet/torspec.git/tree/rend-spec-v3.txt?h=ticket20700_01#n2279
>
> So the idea is that instead of making the HS client/operator have to pass
> around portions of a file containing private and public keys, it is to
> logically seperate them so that the operator only deals with one single file
> when wanting to transmit the keys to a client.
>

Thanks for the fixes David.

Please see last commit of https://github.com/torproject/torspec/pull/24
for some stuff on top of your branch.

Some things we need to think about:
- The ".pubkeys" files are now used internally by Tor, whereas the
  "./client_cfg_lines" file is the one that the operator is supposed to
  look at and interact with. Is it easier for the operator to deal with
  one big file, or with many small files? We should think about that and
  maybe reverse our choices.

  As an example, how is the operator supposed to know which line in
  "./client_cfg_lines" is for which client? In my patch above I used
  # comments to separate lines but that might not be straightforward for
  people.

- Assuming that we are not doing intro auth any time soon, I deleted all
  mentions of ed25519 keys from that side of the spec, in the assumption
  that we will need to introduce them back the right way if we ever
  decide to do intro auth. Is this a good idea or not?

  As an example of the complexity I'm trying to hide, if we keep ed25519
  in the spec, we need to specify how the HidServAuth line knows whether
  a key is x25519 or ed25519.

- Do we need to define new torrc options for service-side and client-side?

Some more things to do:
- Rename "./client_authorized" to "./authorized_clients"?
- Rename "./client_cfg_lines" to 
- What's the "auth-type"? I assume standard.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[David Goulet]

On 18 May (19:03:09), George Kadianakis wrote:
> Ian Goldberg  writes:
> 
> > On Thu, May 10, 2018 at 12:20:05AM +0700, Suphanat Chunhapanya wrote:
> >> On 05/09/2018 03:50 PM, George Kadianakis wrote:
> >> > 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).
> >> 
> >> This will be a great advantage if we can do that because putting two
> >> private keys in the HidServAuth is so frustrating.
> >
> > The private key for intro auth is used to make a signature (that will be
> > different per client), while the private key for desc auth is used to
> > decrypt the descriptor (which will be the same for all clients), no?
> >
> 
> Hm. Both intro auth and desc auth keys are different for each client. In
> the case of desc auth we do that so that we can revoke a client without
> needing to refresh desc auth keys for all other clients.

Following yesterday's discussion on IRC with haxxpop and asn, and some more
today, I worked on a revised version of the spec:

https://gitweb.torproject.org/user/dgoulet/torspec.git/commit/?h=ticket20700_01

Probably will be easier to just read the whole thing instead of the diff:

https://gitweb.torproject.org/user/dgoulet/torspec.git/tree/rend-spec-v3.txt?h=ticket20700_01#n2279

So the idea is that instead of making the HS client/operator have to pass
around portions of a file containing private and public keys, it is to
logically seperate them so that the operator only deals with one single file
when wanting to transmit the keys to a client.

Thoughts?
David

-- 
fbv5H3G6O9hLu6Txl6sNIg/unJ95a7iOi43Afzw8ROs=


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[George Kadianakis]

Ian Goldberg  writes:

> On Thu, May 10, 2018 at 12:20:05AM +0700, Suphanat Chunhapanya wrote:
>> On 05/09/2018 03:50 PM, George Kadianakis wrote:
>> > 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).
>> 
>> This will be a great advantage if we can do that because putting two
>> private keys in the HidServAuth is so frustrating.
>
> The private key for intro auth is used to make a signature (that will be
> different per client), while the private key for desc auth is used to
> decrypt the descriptor (which will be the same for all clients), no?
>

Hm. Both intro auth and desc auth keys are different for each client. In
the case of desc auth we do that so that we can revoke a client without
needing to refresh desc auth keys for all other clients.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Suphanat Chunhapanya]

On 05/14/2018 05:26 PM, George Kadianakis wrote:
> Suphanat Chunhapanya  writes:
> 
>> On 05/09/2018 03:50 PM, George Kadianakis wrote:
>>> 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.
>>
>> I think we have two more things to think about.
>>
>> 1. I forgot to think about the format of client_authorized_pubkeys file.
>> In the client_authorized_pubkeys file, each line should indicate the
>> auth type for which the pubkey is used instead of just specifying the
>> client name and the pubkey. So the line should be as follows.
>>
>>   
>>
>> and, if auth-type is "standard", it will be equivalent to two lines of
>> "desc" and "intro".
>>
> 
> Sounds plausible.
> 
> BTW, what's the role of `client_authorized_pubkeys` in your opinion? Is
> it only used by little-t-tor internally to see which clients are
> recognized or not? IIUC, the onion service operator should not really
> need to use it since it contains pubkeys.

The role of `client_authorized_pubkeys` is to keep all pubkeys of
clients so that we can use them to encrypt the descriptor when the
client auth is enabled.

To specify which clients are recognized, the operator must put the
client names in `HiddenServAuthorizeClient` directive. After that, the
service will use the names in `HiddenServAuthorizeclient` to search for
pubkeys in `client_authorized_pubkeys`. So, if there is a pubkey in
`client_authorized_pubkeys` whose client name is not in
`HiddenServAuthorizeClient`, that key will not be used.

I think the operator needs to use it because, in case the client wants
to generate a keypair itself, the operator needs to put the client's
pubkey in this file.

> 
> BTW, I noticed that in v2, when we enable client auth, the onion service
> also edits the `hostname` file to produce different lines for each
> client, so that the operator can copy-paste them directly to the
> users. Do you find that useful? Do you think we should do it too for v3?

I think we did that because in stealth mode, the hostname will change
depending on the client. In v3, the hostname is always static, so I
think we don't have to do that.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Ian Goldberg]

On Thu, May 10, 2018 at 12:20:05AM +0700, Suphanat Chunhapanya wrote:
> On 05/09/2018 03:50 PM, George Kadianakis wrote:
> > 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).
> 
> This will be a great advantage if we can do that because putting two
> private keys in the HidServAuth is so frustrating.

The private key for intro auth is used to make a signature (that will be
different per client), while the private key for desc auth is used to
decrypt the descriptor (which will be the same for all clients), no?

(Not to mention that you should never use the same key for decryption
and signing.)

   - Ian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[George Kadianakis]

Suphanat Chunhapanya  writes:

> On 05/09/2018 03:50 PM, George Kadianakis wrote:
>> 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.
>
> I think we have two more things to think about.
>
> 1. I forgot to think about the format of client_authorized_pubkeys file.
> In the client_authorized_pubkeys file, each line should indicate the
> auth type for which the pubkey is used instead of just specifying the
> client name and the pubkey. So the line should be as follows.
>
>   
>
> and, if auth-type is "standard", it will be equivalent to two lines of
> "desc" and "intro".
>

Sounds plausible.

BTW, what's the role of `client_authorized_pubkeys` in your opinion? Is
it only used by little-t-tor internally to see which clients are
recognized or not? IIUC, the onion service operator should not really
need to use it since it contains pubkeys.

BTW, I noticed that in v2, when we enable client auth, the onion service
also edits the `hostname` file to produce different lines for each
client, so that the operator can copy-paste them directly to the
users. Do you find that useful? Do you think we should do it too for v3?

Ideally we should ask for feedback from people who use client auth here,
because all these questions are basically UX questions...

> 2. If we want to release the "desc" auth first, I want to say something
> about the config lines.
>
> The "standard" auth config on the client side will not contain the
> ed25519 private key and it will look like this:
>
> HidServAuth onion-address standard x25519-private-key
>
> However, after we release the intro auth, that config line (which does
> not contain the ed25519 private key) should still be valid because, if
> the client upgrades its version, it doesn't need to change the word
> "standard" to the word "desc" in the HidServAuth config line.
>
> On the service side, it will be different. After releasing "desc" auth
> but before releasing "intro" auth, the line in client_authorized_pubkeys
> will look like this (without ed25519 pubkey).
>
>  standard x25519-public-key
>
> But after we release the "intro" auth, that line shouldn't be valid
> anymore because the "standard" line should contain both x25519 and
> ed25519 public keys. It's different from the client side.
>

Yeah this is another great UX question I'm not entirely sure about...

Perhaps the "standard" type should use the keys provided and do the best
it can with those keys. If both keys are provided it should do both "desc"
and "intro" auth, otherwise it should just do the best it can. But to do
this, we need to be able to differentiate "desc" keys from "intro" keys...

> --
>
> I think (1) may not have problems (I guess) but for (2) is it acceptable
> to make ed25519-private-key optional on the HidServAuth "standard"
> config line?
>

Sounds reasonable perhaps... But we need to think more about the UX 
implications!

> --
>
> On 05/09/2018 03:50 PM, George Kadianakis wrote:
>> 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).
>
> This will be a great advantage if we can do that because putting two
> private keys in the HidServAuth is so frustrating.
>

Yeah we should think about this too. I'll try do some research this week.

BTW an alternative approach here when both keys are used would be to
concatenate them into one string so that the user does not need to care
about two different keys, and they should just care about a single
"authentication token".

Thanks for raising these issues haxxpop and sorry for not having
straightforward answers for them just yet!
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Suphanat Chunhapanya]

On 05/09/2018 03:50 PM, George Kadianakis wrote:
> 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.

I think we have two more things to think about.

1. I forgot to think about the format of client_authorized_pubkeys file.
In the client_authorized_pubkeys file, each line should indicate the
auth type for which the pubkey is used instead of just specifying the
client name and the pubkey. So the line should be as follows.

  

and, if auth-type is "standard", it will be equivalent to two lines of
"desc" and "intro".

2. If we want to release the "desc" auth first, I want to say something
about the config lines.

The "standard" auth config on the client side will not contain the
ed25519 private key and it will look like this:

HidServAuth onion-address standard x25519-private-key

However, after we release the intro auth, that config line (which does
not contain the ed25519 private key) should still be valid because, if
the client upgrades its version, it doesn't need to change the word
"standard" to the word "desc" in the HidServAuth config line.

On the service side, it will be different. After releasing "desc" auth
but before releasing "intro" auth, the line in client_authorized_pubkeys
will look like this (without ed25519 pubkey).

 standard x25519-public-key

But after we release the "intro" auth, that line shouldn't be valid
anymore because the "standard" line should contain both x25519 and
ed25519 public keys. It's different from the client side.

--

I think (1) may not have problems (I guess) but for (2) is it acceptable
to make ed25519-private-key optional on the HidServAuth "standard"
config line?

--

On 05/09/2018 03:50 PM, George Kadianakis wrote:
> 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).

This will be a great advantage if we can do that because putting two
private keys in the HidServAuth is so frustrating.





signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[George Kadianakis]

George Kadianakis  writes:

> Suphanat Chunhapanya  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 

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

[teor]

> On 3 May 2018, at 02:09, George Kadianakis  wrote:
> 
> 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.

Careful. If we start by turning both options on or off together, then we won't
have any tests for them being on and off separately.

T
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[George Kadianakis]

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

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Suphanat Chunhapanya]

Hi,

On 04/28/2018 03:59 AM, meejah wrote:
> Then, if the service client has a problem later they have
> to remember NOT copy-paste the whole config when asking for
> help... sounds like lots to go wrong :) and I don't think this can be
> solved by tinkering with the names/layout of torrc options,
> personally...


Agreed. I don't think putting a private key in torrc is a good idea.

Maybe we can put the private key in a separate file and put the path in
the torrc?

For example:
HidServAuth onion-address auth-type path-to-private-key-file

haxxpop



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Suphanat Chunhapanya]

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


What do you all think?

Cheers,
haxxpop



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[teor]

Hi,

> On 28 Apr 2018, at 06:59, meejah  wrote:
> 

> After reading the spec diff and your mail, I'm still not sure I
> understand the distinction -- if the x25519 is used to decrypt the
> descriptor then:
> 
>> The spec says that the client must have both keys and use both to
>> authenticate, but, for me, these two things are quite independent. I
>> think they can be considered two different authentication types. The
>> service should be able to enable one and disable the other. For example,
>> If I disable the x25519 while I enable ed25519, I can add a new client
>> immediately without the need to rotate the intro points.
> 
> ...how does this work? If the client doesn't have the x25519 key how can
> it access the descriptor?

If the service does not encrypt the descriptor with an x25519 key, then the
client does not need a key to read it.

> The spec says that the client must have both keys and use both to
> authenticate, but, for me, these two things are quite independent. I
> think they can be considered two different authentication types. The
> service should be able to enable one and disable the other. For example,
> If I disable the x25519 while I enable ed25519, I can add a new client
> immediately without the need to rotate the intro points.
> 
> If rotating intro points is not an issue and the only purpose of ed25519
> is to have more fine-grained access control, the current spec is fine.
> But if rotating intro points is an issue, we should rethink about this.
> 
> So, I created a PR for the change in torspec.
> https://github.com/torproject/torspec/pull/7
> (in the PR, the x25519 auth is called 'basic' and the ed25519 auth is
> called 'intro')

Please use different words from v2 to avoid confusion.

Please use words that describe what a thing *is*, not how secure it
is, or what it should be used for, or what level of the design it is on.
(We made that mistake when naming "hidden services".)

I would recommend:
* "descriptor" for descriptor auth
* "intro" for into auth

> We need your opinions about this.
> Should we let the service enable one while disable the other?

Yes, they have different security properties.

For example, a Ricochet-like peer to peer messaging protocol
would like to be able to revoke one contact (intro auth), without
disconnecting all the rest (descriptor auth).

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

T___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[meejah]

Suphanat Chunhapanya  writes:

After reading the spec diff and your mail, I'm still not sure I
understand the distinction -- if the x25519 is used to decrypt the
descriptor then:

> The spec says that the client must have both keys and use both to
> authenticate, but, for me, these two things are quite independent. I
> think they can be considered two different authentication types. The
> service should be able to enable one and disable the other. For example,
> If I disable the x25519 while I enable ed25519, I can add a new client
> immediately without the need to rotate the intro points.

...how does this work? If the client doesn't have the x25519 key how can
it access the descriptor?


Also, separately addressing the issue of configuration and terminology, I
think it's probably best if "users" (service operators and clients)
don't actually have to touch the keys.

This sounds fraught with peril: a service operator has to copy-pasta the
right half of the correct two keys, securely deliver them to a client
and the client has to put them in the right place in a
config-file. Then, if the service client has a problem later they have
to remember NOT copy-paste the whole config when asking for
help... sounds like lots to go wrong :) and I don't think this can be
solved by tinkering with the names/layout of torrc options,
personally...

-- 
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] HS v3 client authorization types

[Suphanat Chunhapanya]

As I am currently implementing the client authorization for onion
service v3 (https://github.com/torproject/tor/pull/36), I found some
problems in how we should let the users configure the client auth for
their services.

Before getting into the problem, I will explain how it works first.

--
Each client will have two private keys to authenticate with the service.
One is x25519 key and the other is ed25519 key.

The x25519 one is used to decrypt the descriptor when the client wants
to access the service, so if the client is not authorized, it will never
know the introduction points, the intro auth keys, and so on, and then
it absolutely cannot access the service.

The ed25519 one is for another layer of authentication. Even if the
client can decrypt the descriptor using the x25519 private key, it still
need to have the ed25519 to authenticate itself directly to the service
using the extension field in INTRODUCE1 cell.

At first glance, it seems that the ed25519 one is not necessary because,
if the client is able to decrypt the descriptor, it already means the
client is already authenticated. Why do we need to have another layer of
authenticate?

The answer is that the ed25519 provides more find-grained access control
for example:

1) you could use it to revoke a client without the need to rotate all
the intro points and push new descriptor.
2) you can have more fine-grained control on your users and potentially
offer different types of access structure to different users using their
ed25519 keys as identifier.
--

The spec says that the client must have both keys and use both to
authenticate, but, for me, these two things are quite independent. I
think they can be considered two different authentication types. The
service should be able to enable one and disable the other. For example,
If I disable the x25519 while I enable ed25519, I can add a new client
immediately without the need to rotate the intro points.

If rotating intro points is not an issue and the only purpose of ed25519
is to have more fine-grained access control, the current spec is fine.
But if rotating intro points is an issue, we should rethink about this.

So, I created a PR for the change in torspec.
https://github.com/torproject/torspec/pull/7
(in the PR, the x25519 auth is called 'basic' and the ed25519 auth is
called 'intro')

We need your opinions about this.
Should we let the service enable one while disable the other?
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?

Cheers,
haxxpop

This is a discussion log that we had earlier.

[22:39:23]  v3 "basic" auth is different from v2 "basic" auth,
right? Perhaps a different name-string for the v3 one would be good?
[22:39:44]  meejah: good point
[22:39:57]  perhaps we can name it "pubkey" auth or something more UX-y
[22:40:35]  asn: sounds good to me (my perspective is to avoid
naming-weirdness for controllers and having to explain to users "well,
this 'basic' is different from this other 'basic' because you said
version=3")
[22:40:43]  right
[22:40:44]  makse sense
[22:40:51]  haxxpop: ^ what do u think
[22:40:51]  ?
[22:45:01]  meejah, asn yes I agreed. maybe we should change it
to something else
[22:46:10]  meejah, asn In fact, the word 'basic' appears only
once in the v3 spec !
[22:48:05]  haxxpop: yeah... perhaps we can rename it to "pubkey"
which describes it pretty well for nerds. or to "standard" which is a
synonym for "basic" and it will confuse everyone.
[22:50:59]  asn, I think both "basic" and "intro" use pubkeys.
[22:51:26]  asn, I think if we call "basic" "pubkey", it may
imply that "intro" doesn't use pubkeys.
[22:51:35]  true
[22:52:20]  i'm still not sure if i like:
[22:52:20]   +HiddenServiceAuthorizeClient basic
client-name,client-name,...
[22:52:20]   +HiddenServiceAuthorizeClient intro
client-name,client-name,...
[22:52:30]  mainly because it's gonna be quite hard to explain to
people what these two lines mean
[22:52:34]  (to hs operators)
[22:52:37]  like what's the difference
[22:52:42]  and usually they should have both enabled
[22:52:53]  what i imagined initially is that we would keep the
torrc logic the same
[22:53:04]  and maybe expose a torrc option for advanced users to
do HiddenServiceDisableIntroAuth
[22:53:07]  or something
[22:53:11]  anyway i need to think about this!
[22:53:25]  asn, Nice point
[23:08:35]  asn: haxxpop: "pubkey" sounds good to me. People who
are "just clients" probably don't care what the string is (? maybe? UX
people?) and people running the services probably count as "nerds" :)
[23:08:59]  agreed
[23:09:02]  (but, I don't personally understand what these
schemes are so maybe I shouldn't be naming them ;)
[23:09:08]  ideally those things should not be exposed to the users
anyway
[23:09:19]  they should be wrapped by the browser or something
[23:11:46]  asn: in