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

Hi,

On 28 Apr 2018, at 06:59, meejah <meejah@xxxxxxxxx> 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)