[tor-dev] HS v3 client authorization types

[teor]

Hi,

> On 28 Apr 2018, at 06:59, meejah <meejah at meejah.ca> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20180428/3500f411/attachment.html>