Post by Michael RogersPost by George KadianakisPost by George Kadianakishere is a patch with an alternative directory format for v3 client auth
https://github.com/torproject/torspec/pull/23
Thanks for making me edit the spec because it made me think of various
details that had to be thought of.
Let me know if you don't like it or if something is wrong.
Minor clarification: line 2298 says the keypair is stored, it might be
clearer to say the private key is stored.
Nitpick: should the directory be called "client_authorized_privkeys" if
it might contain private keys, public keys, or a mixture of the two?
Good points in both cases. Will fix soon (along with other feedback if received).
Other than that, what do you think about the whole concept? Too complex?
Logical? Too much?
Cheers for the feedback! :)
Sorry for being late to the party - I just this morning finished reading
the thread from 2016 where the client auth design was hashed out. :-/
I think putting each client's keys in a separate file makes a lot of sense.
At a higher level there are some things I'm not sure about. Sorry if
this is threadjacking, but you said the magic words "whole concept". ;-)
Thanks for raising these issues and for taking the time to read the
previous thread. We really need feedback like this from people who have
used our systems like you :)
Post by Michael RogersFirst, Ed25519-based authentication ("intro auth"). Could this be punted
to the application layer, or is there a reason it has to happen at the
Tor layer?
Yes, it could be stuffed into the application layer. However that could be
an argument for everything (including end-to-end encryption of onions).
It might be the case that some application-layer protocols don't allow
any sort of pluggable authentication to happen on top of them, or that
users wouldn't want to enable them for some reason. Does this feel like
an artificial reason to you?
Another positive thing about intro auth is that it allows fine-grained
control over authentication, potentially allowing different tiers of
users etc.
Also see https://lists.torproject.org/pipermail/tor-dev/2018-May/013155.html
Post by Michael RogersSecond, X25519-based authorization ("desc auth"). If I understand right,
using asymmetric keypairs here rather than symmetric keys makes it
possible for the client to generate a keypair and send the public key to
the service over an authenticated but not confidential channel. But the
client may not know how to do that, so we also need to support an
alternative workflow where the service generates the keypair and sends
the private key to the client over an authenticated and confidential
channel.
The upside of this design is the ability to use an authenticated but not
confidential channel (as long as the client and service understand which
workflow they need to use). The downside is extra complexity. I'm not
really convinced this is a good tradeoff. But I'm guessing this argument
has already been had, and my side lost. :-)
Yes, you have described it very well.
And I agree that the tradeoff is complicated.
Post by Michael RogersThird, what's the purpose of the fake auth-client lines for a service
that doesn't use client auth? I understand that when a service does use
client auth, it may not want clients (or anyone else who knows the onion
address) to know the exact number of clients. But when a service doesn't
use client auth, anyone who can decrypt the first layer of the
descriptor can also decrypt the second layer, and therefore knows that
the auth-client lines are fake. So are they just for padding in that
case? But the first layer's padded before encryption anyway.
Yes, fake auth-client lines when client auth is disabled are not very
useful as you point out (also see #23641).
Post by Michael RogersFourth, what goals does desc auth achieve in the v3 design? If I
understand right, in v2 its major goal was to hide the intro points from
everyone except authorised clients (including HSDirs). In v3 the intro
points are already hidden from anyone who doesn't know the onion address
(including HSDirs), so this goal can be achieved by not revealing the
onion address to anyone except authorised clients.
I'm probably missing something, but as far as I can see the only other
goal achieved by desc auth is the ability to revoke a client's access
without needing to distribute a new onion address to other clients. This
seems useful. But again, I'd ask whether it could be punted to the
application layer. The only advantage I can see from putting it at the
Tor layer is that the list of intro points is hidden from revoked
clients. Is there a real world use case where that's a big enough
advantage to justify putting all this authorisation machinery at the Tor
layer? Or maybe there are other things this design achieves that I
haven't thought of.
Yes, you identified the point of desc auth correctly.
Another very important reason to have an authorization system inside
Tor, is because it allows only authorized clients to rendezvous (and in
general directly interact) with the onion service. That can mitigate all
sorts of guard discovery and correlation attacks that could be doable by
anyone, and restrict them only to authorized users.
Of course the above is achieved with either desc auth or intro
auth. Having both of them does not offer any benefits in this direction.
Post by Michael RogersAnyway, sorry for the bag of assorted questions. I've been meaning to
catch up on all the discussions where they've probably been answered
already, but it's becoming clear that's a losing battle, so I'd better
just send them. Apologies if they're redundant or uninformed.
Thanks for raising these questions, they are very important. Please keep
them coming.
We might be trying to achieve too many things here, or trying to design
a too convoluted system, so we need feedback to understand the user
expectations and threat models we should be trying to satisfy.