[messaging] RFC: Proposal for alternative primary identifiers in mobile messaging (specifically Signal)

[Trevor Jameson]

Sorry for the delayed reply, been thinking about this for a few days.

On reflection, I think email identifiers can meet the same bar as an SN (as
in the proposal), as long as there is a  'registration lock' type feature
(same as phone numbers as in Signal) to mitigate compromise of the email
account.

> I think email addresses would solve the problem of letting people create
throwaway identities more easily, while also preserving all of the existing
Signal user experience. Yes there are security drawbacks to this approach,
but there are also huge UX wins, especially in terms of simplicity and
consistency.

On second thought, I agree the UX wins of an email address outweigh the
security value of an intrinsic hash-based identifier. Lets do email
addresses instead.


Implementing support for email addresses in signal is actually easier than
the original proposal - no funky hashes + challenge-response verification
when signing up and sharing a signalling-key/registrationID. Client
implementation is probably about the same level of complexity.

Thanks for all the feedback,
-T

On Tue, May 29, 2018 at 10:33 AM, Tony Arcieri <bascule at gmail.com> wrote:

> On Mon, May 28, 2018 at 8:06 PM Trevor Jameson <trevorjameson87 at gmail.com>
> wrote:
>
>> This wins the UX game because emails are memorable, short and can be put
>> in an existing users contacts. SNs and hash-based proposals arent
>> memorable, but thanks to the prevalence of deeplinking and QR codes, they
>> can be trivially shared by users. Snapchat did this and proved the
>> effectiveness of this UX.
>>
>
> These are two completely different experiences for the user though.
>
> In the case of an email address, it would work exactly as Signal does
> today where it can auto-discover Signal contacts based on your phone's
> contacts without the need for Signal to store a social graph. It also means
> the user has an identity that outlives any one cryptographic key and
> therefore supports key rotation.
>
> In the case of an identifier based on a cryptographic key, it behaves
> quite differently: we've moved out of the "human meaningful" section of
> Zooko's triangle into the "decentralized" one. In doing so a lot of the
> nice properties of these identifiers are lost:
>
> - Auto-discovery via Contacts won't work for this approach, since we don't
> have a stable, reusable, human meaningful identifier for people. So, these
> identifiers can only be exchanged securely via things like QR codes, or
> bootstrapping via another secure channel (or potentially insecure channel)
> - Key rotation won't be automatic and seamless. This also raises questions
> about how multi-device support should be handled.
>
> Beyond the obvious (backup your keys somewhere), I dont have a good answer
>> for this. The best UX here would be some artifact you store offline
>> ('print' a QR code, download to a USB stick) but this has its own set of
>> issues.
>>
>> At some level this is an inherent problem of online identity, and by
>> keying off email addresses, we are only deferring the problem to the email
>> password/2FA/recovery-mechanisms. Personally, I rather the trade-off
>> where we address backup ourselves.
>>
>
> From a UX perspective, email recovery is something most users will
> understand. Printing out a QR code is comparatively quite weird, and then
> there's the question of even printing anything securely (I suppose you can
> print out a KDF input/salt or keywrapped key which needs an additional
> password component).
>
> We can also explicitly not address this: By explicitly stating our
>> alternative identifiers are non-recoverable if you loose key material, and
>> you accept this trade-off. This is okay as phone-based identifiers remain
>> an option for users who dont lean this way.
>>
>
> This sounds like the sort UX-compromising power-user feature that Signal
> has typically avoided as opinionated software with a simple interface. It
> feels like it accomplishes largely the same ends as safety numbers (verify
> cryptographic keys), using the same UX as safety numbers (confirm a QR
> code). It simplifies the creation of throwaway identities by reintroducing
> a UX that's giving me flashbacks to PGP/GPG and keysigning parties.
>
> I think email addresses would solve the problem of letting people create
> throwaway identities more easily, while also preserving all of the existing
> Signal user experience. Yes there are security drawbacks to this approach,
> but there are also huge UX wins, especially in terms of simplicity and
> consistency.
>
> --
> Tony Arcieri
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20180531/e3fc1882/attachment.html>