[tor-dev] HS v3 client authorization types

[George Kadianakis]

David Goulet <dgoulet at torproject.org> writes:

> On 18 May (19:03:09), George Kadianakis wrote:
>> Ian Goldberg <iang at cs.uwaterloo.ca> 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.