Re: [tor-bugs] #17961 [Tor Messenger]: Evaluate CONIKS as an authenticator

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#17961: Evaluate CONIKS as an authenticator
---------------------------+---------------------
 Reporter:  arlolra        |          Owner:
     Type:  defect         |         Status:  new
 Priority:  Medium         |      Milestone:
Component:  Tor Messenger  |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:                 |  Actual Points:
Parent ID:                 |         Points:
  Sponsor:                 |
---------------------------+---------------------

Comment (by masomel):

 Here are the main design and deployment questions we've discussed about
 CONIKS so far:

 ''Q: Can Tor Messenger become a CONIKS provider although we donât hand out
 identities?''

 A: To use CONIKS as a key verification system, Tor Messenger does not need
 to hand out identities to its users in its own namespace. As long as each
 end user has *some* name (which could be their Twitter handle or the name
 they use for XMPP), a public key can be bound to this name, and itâs this
 name-to-key binding that CONIKS would verify. The CONIKS server can be
 agnostic to the original namespace of each of the names. This makes for a
 heterogenous naming scheme, but whatâs important is that each name is
 unique in the Tor Messenger namespace.

 ''Q: If Tor Messenger acts as the CONIKS provider for users using a wide
 variety of naming schemes, how can we ensure that the that the @alice
 registered with the CONIKS server corresponds to the @alice identity on
 Twitter?''

 A: We can ask for a proof of ownership of the name, e.g. by sending an
 email with a confirmation code, a Twitter dm or an XMPP offline message.
 This isnât an ideal solution but it does raise the bar for an attack
 because it would require the attacker to gain access to the account
 receiving the confirmation code, which seems to be enough of a deterrent
 in most cases today.

 ''Q: Is it reasonable to ask each communication service provider,
 especially in a federated system like XMPP, to act as a CONIKS provider?''

 A: Convincing a large portion of providers to act as CONIKS servers would
 be a pretty difficult task. One idea could be to have a single CONIKS
 server for Tor Messenger, but to convince other service providers to act
 only as CONIKS auditors, which ensure that the CONIKS server is behaving
 properly (i.e. not equivocating or otherwise tampering with its usersâ
 keys). We think that because communication service providers already look
 for ways to protect their usersâ security and privacy, this could serve as
 an incentive to run a CONIKS auditor. Plus, as we show in the paper, the
 burden to be a CONIKS auditor is significantly lower, so that might help
 in convincing these services as well. We also imagine that third parties
 like the EFF could run CONIKS auditors.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17961#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs