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

[Tony Arcieri]

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/20180529/9701b390/attachment.html>