On 06 Dec (17:23:10), Lunar wrote: > Hi! > > Sorry to be late to the party. I still haven't seen UX concerns fully > addressed, and I think we should not create a specification that will > make the life of our users harder if we can avoid it. I believe it can be addressed by a good UI in TBB mostly to fit this client authorization proposal. Answers below. > > s7r: > > George Kadianakis wrote: > > > I have a more mature torspec branch now for your eyes and only. Please > > > see branch `prop224_client_auth_4` in my torspec repo: > > > https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_auth_4 > > > > > > The changes are based on the feedback and discussion on this thread. > > > > I would like to state, since I seen it in older posts on this thread, > > that I dislike the idea of generating at client side low entropy ed25519 > > key pairs based on simple passwords. It may sound simple and good from > > UX point of view, but we are decreasing the security of a very secure > > auth scheme with it and enabling an over-the-hand practice that keys > > come from client to HS and not vice-versa. > > I hope we can find a balance between “a very secure auth scheme” that > will be too cumbersome to use for most users and “a secure and usable > auth scheme”. > > I've been hoping we could get a nice UI in Tor Browser to access > authenticated onion services for a while now (#8000). The difficult part > UX-wise is that there is no way to differentiate between an onion > service that is either non-existant, temporary unavailable or > authenticated. (But it's good for security, so let's keep things that > way.) > > How are users expected to give enter the private key in Tor Browser? > Does the key have to be saved on disk? What should I have to do to > browse an authenticated onion service when running under Tails without > persistence enabled? We thought about this a bit (maybe not in depth) but the idea here is that an HS operator will have a choice between creating an authentication token for a specific client or add one that a client gave it to her. For a client, we kept the "token" to be a one liner containing the key material and an identifier. So it becomes a matter of "How the client generates that token?" and "How it is exchanged between client and operator?" I think the way to go here is for sure an integration in TBB. First option would be for a user to enter a password and the keys are derived from it and we output the one line that the user should give to the HS operator. If the HS operator already have that line configured in, well great, it addresses the Tails use case where you move around and you simply need to input your password to get the right token that you've already gave to the HS. The second option would be to "Generate token for me", output the line and give out-of-band to HS operator that one liner. And the third option would be to "Enter token here" which is the case where HS operator gives out token to client. All those are a UI challenge but I think will be _great_ improvement to the current state of things but they are all on TBB side. One thing that we unfortunately can't solve is the "give token to HS operator automagically", it has to be out-of-band else we are getting into another world of complexity. HOWEVER, we could think of a proposal to have some sort of "Auth Server Transport" support which you could tell your tor to fetch token from that "auth server" but that is some big piece of work. > > I don't see how to streamline support for an amnesic system if I have to > generate a unique keypair that I need to give to the onion service > owner beforehand. To be honest, it would be quite amazing to pull off a TBB UI for this at the same time as we roll out prop224 in a tor stable :) with the use case of amnesic system. > > Should we draw inspiration from miniLock? > https://minilock.io/files/HOPEX.pdf (see slide 35) > > If I try to think of my experience as an admin, I see several cases > where it would be much easier to give authentication token to users > myself. User story: > > Elena has set up an Etherpad instance on her private server. She > generates a handful of access codes before going to meet the newly > formed copwatch chapter. After the end of the meeting, she can give > out a piece of paper to all attendees so they can access the minutes > and write up reports together in the future. > > You really don't want to have all attendees bring their computer or > require them to meet with Elena at a later time. Yeah... the client token I've been talking about is a bit long actually but we have to to ensure some semblance of modern security that is ECC keys of 32 bytes. However, what we could do server side is generate a client key associated with some keywords that if put in TBB UI would generate same client key (a bit like pond does with the words). Thanks for the feedback! David > > Hope that helps, > -- > Lunar <lunar@xxxxxxxxxxxxxx> > _______________________________________________ > tor-dev mailing list > tor-dev@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev