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

[Trevor Jameson]

Thanks all for your detailed replies. I'll try and comment on all these,
apologies on the order. I'm interested to hear your thoughts on my
(opinionated) position as I most definitely am surrounded by an echo
chamber IRL :)


WRT email addresses as a primary identifier, I have concerns:

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.

The main failing of emails as an identifier IMHO is that we now make the
security properties of our identifier constrained by the security
properties of email. This is a solvable problem with the correct use of TLS
and various DNS records, but this is non-trivial. I would much rather
side-step all of this. Solving that with shadow registries and the like
address the problem but multiplies complexity and subsequently the number
of failure modes. This further compounds difficulties when constructing a
threat matrix or a user/org reasoning against their threat model.

Also, homoglyph attacks are possible on anything a user could recognize
(email identifiers, usernames), and these are terrifyingly easy to pull
off. Just this attack alone imo means we need to stop relying on users (ie:
do I recognize this email address) for verification and exclusively use 1)
artifacts that dont rely on humans and 2) computers for verification.
Phishing is well understood by researchers yet highly effective (whelp).

My last issue with email is provenance. Even though throwaway email
addresses are easier than throwaway phone numbers, adversaries still have
something to follow up on.

WRT recovery - "phone droped into toliet" use-case:

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.

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.

Thanks all,
-T



On Mon, May 28, 2018 at 4:28 PM, Max Skibinsky <max at skibinsky.com> wrote:

> I've written it up on the signal forums here: https://community.signal
>> users.org/t/a-proposal-for-alternative-primary-identifiers
>>
>
> ​Trevor, we actually implemented simular schema few years ago in "Zax"
> relay: https://github.com/vault12/zax#readme  Address space is global for
> all, address is a hash of a public key, and initial key exchange bootstraps
> via SMS (http://bit.ly/zax-invites)
>
> IMHO, the elephant in the room here is highly popular use case "phone
> droped into toilet", which is about few times a year for a casual user. As
> long as you need to support fresh phone bootstrap for casuals then phone
> number remain "casual ID" - goes without saying casual user has no clue how
> to backup her old phone, and she long forgoten whatever sequence of letters
> you told her 4 months ago.
>
> Right now everyone accepts the compromise of having one instant of
> weakness (when phone number bootstraps long term PKI exchange) for the
> security of continious operations after such bootstrap took place. Whatever
> solution you end up doing it has to address the critical use case of user
> getting completely fresh phone, no old artefacts preserved, and the only
> connecton to his "past life" is his phone #.
>
> - Max
> - vault12.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20180528/878538d9/attachment.html>