[tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

Tue Dec 6 16:51:57 UTC 2016

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 at torproject.org>

> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 585 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161206/083c6bda/attachment-0001.sig>