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

[George Kadianakis <desnacked@xxxxxxxxxx>]

Suphanat Chunhapanya <haxx.pop@xxxxxxxxx> 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.
>
> <client-name> <auth-type> <pubkey>
>
> 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).
>
> <client-name> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev