Hello haxxpop and David,
here is a patch with an alternative directory format for v3 client auth crypto key bookkeeping as discussed yesterday on IRC: 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.
Cheers!
On 10/07/18 19:58, George Kadianakis wrote:
here is a patch with an alternative directory format for v3 client auth crypto key bookkeeping as discussed yesterday on IRC: 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?
Cheers, Michael
Michael Rogers michael@briarproject.org writes:
On 10/07/18 19:58, George Kadianakis wrote:
here is a patch with an alternative directory format for v3 client auth crypto key bookkeeping as discussed yesterday on IRC: 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! :)
On 11/07/18 14:22, George Kadianakis wrote:
Michael Rogers michael@briarproject.org writes:
On 10/07/18 19:58, George Kadianakis wrote:
here is a patch with an alternative directory format for v3 client auth crypto key bookkeeping as discussed yesterday on IRC: 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". ;-)
First, 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?
Second, 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. :-)
Third, 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.
Fourth, 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.
Anyway, 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.
Cheers, Michael
Michael Rogers michael@briarproject.org writes:
On 11/07/18 14:22, George Kadianakis wrote:
Michael Rogers michael@briarproject.org writes:
On 10/07/18 19:58, George Kadianakis wrote:
here is a patch with an alternative directory format for v3 client auth crypto key bookkeeping as discussed yesterday on IRC: 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 :)
First, 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
Second, 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.
Third, 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).
Fourth, 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.
Anyway, 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.
Quoting George Kadianakis (2018-07-11 19:26:06), as excerpted
Michael Rogers michael@briarproject.org writes:
On 11/07/18 14:22, George Kadianakis wrote:
Michael Rogers michael@briarproject.org writes:
First, 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.
That might be true, but it's not an argument for intro auth, because application-layer authentication offers that too.
Also see https://lists.torproject.org/pipermail/tor-dev/2018-May/013155.html
Fourth, 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.
asn said that a benefit of Tor-level authentication is that users may be likely to accidentally reveal their onion service address, e.g. by posting screenshots, or copying and pasting the URL, but are less likely to accidentally reveal their separate authentication credentials.
I thought of a minor benefit of desc auth: revoked clients are prevented entirely from attacking the onion service, e.g. by DDoS.
Alex Xu alex_y_xu@yahoo.ca writes:
Quoting George Kadianakis (2018-07-11 19:26:06), as excerpted
Michael Rogers michael@briarproject.org writes:
On 11/07/18 14:22, George Kadianakis wrote:
Michael Rogers michael@briarproject.org writes:
First, 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.
That might be true, but it's not an argument for intro auth, because application-layer authentication offers that too.
Also see https://lists.torproject.org/pipermail/tor-dev/2018-May/013155.html
Fourth, 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.
asn said that a benefit of Tor-level authentication is that users may be likely to accidentally reveal their onion service address, e.g. by posting screenshots, or copying and pasting the URL, but are less likely to accidentally reveal their separate authentication credentials.
I thought of a minor benefit of desc auth: revoked clients are prevented entirely from attacking the onion service, e.g. by DDoS.
True. This is actually one of the most useful benefits of client auth right now: blocking introduction requests from non-authenticated clients and hence blocking guard discovery or DDoS attacks.
George Kadianakis desnacked@riseup.net writes:
Hello haxxpop and David,
here is a patch with an alternative directory format for v3 client auth crypto key bookkeeping as discussed yesterday on IRC: 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.
Hello again,
there have been many discussions about client auth since that last email a month ago. Here is a newer branch that we want to get merged so that we proceed with implementation: https://github.com/torproject/torspec/pull/33
The first commit is the same as in the original post, and all subsequent commits are improvements on top of it.
Here are a few high-level changes that were made after discussion:
- Ditched intro auth for now, since descriptor auth is sufficient for our threat model, and trying to support two different auth types would complicate things.
- Opted for a KISS design for now where we don't ask Tor to generate client auth keys neither on the client side or on the service side. For now we assume that client/service-side generated their keys with an external tool, and we will build such tools in the future, instead of spending too much time bikeshedding about it right now.
- Client auth is enabled if the client auth directory is populated with the right files, instead of relying on torrc switches etc.
Furthermore, the last three commits are quick mainly-cosmetic changes I did alone before posting this here. Inform me if you don't like those.
I'll let this simmer here for a few days before merging it in torspec. Let me know if you have questions! Thanks for reading!
George Kadianakis desnacked@riseup.net writes:
George Kadianakis desnacked@riseup.net writes:
Hello haxxpop and David,
here is a patch with an alternative directory format for v3 client auth crypto key bookkeeping as discussed yesterday on IRC: 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.
Hello again,
there have been many discussions about client auth since that last email a month ago. Here is a newer branch that we want to get merged so that we proceed with implementation: https://github.com/torproject/torspec/pull/33
The first commit is the same as in the original post, and all subsequent commits are improvements on top of it.
Here are a few high-level changes that were made after discussion:
Ditched intro auth for now, since descriptor auth is sufficient for our threat model, and trying to support two different auth types would complicate things.
Opted for a KISS design for now where we don't ask Tor to generate client auth keys neither on the client side or on the service side. For now we assume that client/service-side generated their keys with an external tool, and we will build such tools in the future, instead of spending too much time bikeshedding about it right now.
Client auth is enabled if the client auth directory is populated with the right files, instead of relying on torrc switches etc.
Furthermore, the last three commits are quick mainly-cosmetic changes I did alone before posting this here. Inform me if you don't like those.
I'll let this simmer here for a few days before merging it in torspec. Let me know if you have questions! Thanks for reading!
FWIW, the above spec branch has been merged upstream to torspec.git!
Feedback is still welcome and we will patch upstream if needed! :)
-
Alex Xu -
George Kadianakis -
Michael Rogers