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

[Phillip Hallam-Baker]

I have been thinking about the problem on the lines Tony suggests and I
think I might have a solution.

First off, yes hashes of public keys are great, see my UDF/SIN proposal
which uses Base32 encoding so the identifiers can be read out over a phone.

mb2gk-6duf5-ygyyl-jny5e-rwshz

A SIN is a UDF that is bound to an Internet address to create a Vtrong
Internet Name
http://mathmesh.com/Documents/draft-hallambaker-sin.html

alice at mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com

Both are useful, neither is very usable. For that we need a registry of
some sort.


One approach is to use a B****Chain and assign identifiers on a first come
first served basis which allows for user friendly identifiers if you get in
quick.

Another is to use techniques to compress the hash result without losing
work factor. If the first 25 bits of a hash are zero, they can be omitted.
UDF supports this (there is a MSFT patent that covers some ways of doing
this).


However, none of these are really email addresses as we recognize them.
They are really machine readable identifiers that are better used under the
covers. So we start off with an email address or phone number and translate
to one of these.

OK so here is the alternative.


We start off trying to resolve the email address in the normal fashion.
alice at example.com in the FOO protocol means 'look at the SRV/TXT records
for _foo._tcp.example.com to find the service'.

That is fine for phill at hallambaker.com but what about hallam at gmail.com if
Google isn't playing ball?

The way I would handle these is with a shadow registry which is only
consulted AFTER the DNS service. So I can register with the shadow registry
today and make use of the service and people can contact me until Google
decides to provide support and publishes SRVs to their own service.


Ths shadow registry should ideally be open and unencumbered (not another
XRI scheme please). It should validate registration requests against the
authoritative source. So I have to authenticate myself to claim
hallam at gmail.com on the service. (This is of course pretty easy if OpenID
is supported).

When names are registered in the shadow registry, the registration is bound
to the hash of the users long term profile public key and enrolled in a
hash chain.


When using a system of this sort, the process would be something like:

I decide to use the OpenDARE messenger service provided by prismproof.org
(i.e. my personal node).

I enroll as hallam at prismproof.org and register hallam at gmail.com as an alias
and point the SRV for hallambaker.com to prismproof.org. At this point,
people can contact me by any one of hallam at prismproof.org, hallam at gmail.com
or phill at hallambaker.com using end-to-end secure messaging.

In OpenDARE, there is a hierarchy of messages ranging from contact requests
through to sending executable code. So anyone can send me a contact request
but they can only send me longer messages if I accept them as a contact at
which point we exchange our credentials and a long term binding is
established.


Now OpenDARE (Data At Rest Encryption) is one messaging protocol that we
are currently building. But the infrastructure we use to achieve the
usability and manage the private keys, devices etc. is designed to be
multi-application. This is in part so we can provide support for legacy
protocols like S/MIME, OpenPGP, SSH, etc. But it could be used by new
applications as well. And in particular, contacts can be shared across
applications.


We could do the exact same thing for telephone numbers only in that case I
see it more as a transitional technology. Telephone numbers are an
identifier that should go away in the near future.




On Mon, May 28, 2018 at 3:02 PM, Tony Arcieri <bascule at gmail.com> wrote:

> Isn't the best alternative to a phone number an email address? It's
> information people may already have in their Contacts so it should map well
> to all of Signal's existing contact flows, and the problem of verifying
> ownership of an email address is well-understood (I say this as someone
> with p=reject DMARC rules)
>
> On Mon, May 28, 2018 at 11:22 AM Trevor Jameson <trevorjameson87 at gmail.com>
> wrote:
>
>> (Just found this in my drafts folder, having intended to send a week ago.
>> Oops.)
>>
>> I wrote a proposal for alternative identifiers (as opposed to the common
>> practice of using phone numbers) that has better properties, and I would
>> like to share it here for review and comment. My broad intention is to
>> implement this, assuming I am able to get in contact with OWS and get an OK
>> from them first.
>>
>> I've written it up on the signal forums here: https://community.
>> signalusers.org/t/a-proposal-for-alternative-primary-identifiers
>>
>> Cheers!
>> -T
>> _______________________________________________
>> Messaging mailing list
>> Messaging at moderncrypto.org
>> https://moderncrypto.org/mailman/listinfo/messaging
>>
>
>
> --
> Tony Arcieri
>
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20180528/a8d11062/attachment.html>