[tor-dev] HS v3 client authorization types
teor2345 at gmail.com
Fri Apr 27 23:19:26 UTC 2018
> 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.
> (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.)
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.)
(Default: descriptor, intro)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tor-dev