George Kadianakis desnacked@riseup.net writes:
Also, it means that clients need to _securely_ send credentials to the HS operator and then they need to _wait_ till the HS operator adds those creds to Tor, before they are able to visit the HS.
One thing that might help here is Brian Warner's "magic wormhole" (http://magic-wormhole.io) -- which supports Tor. This would answer the "how to securely communicate the key" part, at the expense of both parties needing to be online at the same time. Basically, instead of exchanging the HS credentials directly, you'd share a "wormhole code" which is a SPAKE2 one-time password.
If, for example, a controller library like txtorcon added support for this, the HS operator (Bob) would run some command on their side ("invite alice") which would add credentials for Alice to Tor (via ADD_ONION_CLIENT or something) and give Bob a "wormhole code". Bob gives the code to Alice (ideally securely, but not nearly as critical here as with "actual" keys), who would run something app-specific on their side (e.g. "accept invitation") and type in the code they were given. The command running on Bob's side would pass the actual HS credentials (via the now-established wormhole) to Alice's running application (which then also would use some controller command to add the client credentials to their Tor instance).
So, neither Alice nor Bob ever actually see any keys at all.
We should probably speak with people that use client auth to tell us if this UX will break their model.
+1 It would be great to know how people actually exchange these things currently :)