Changes between Initial Version and Version 1 of Ticket #17961, comment 2


Ignore:
Timestamp:
Mar 12, 2016, 4:20:24 PM (4 years ago)
Author:
arlolra
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #17961, comment 2

    initial v1  
    55A: 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.
    66
    7 ''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?''
     7''Q: If Tor Messenger acts as the CONIKS provider for users using a wide variety of naming schemes, how can we ensure that the @alice registered with the CONIKS server corresponds to the @alice identity on Twitter?''
    88
    99A: 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.