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