[Cryptography] A naming and key distribution infrastructure for the Mesh

Sat Sep 26 17:08:46 EDT 2020

For the mesh to work at scale, onboarding and discovery will have to build
on top of existing naming infrastructures (telephone, SMTP, banking, ...),
regardless of how spammy they are.

Let assume Alice (resp. Bob) is the mesh participant that can prove
possession of Alice's mesh record (public key).

If Bob has Alice's email contact entry named "alice at gmail.com", Bob wants
to use this to discover Alice's mesh record.
If Bob has Alice's phone contact entry named "+1-617-666-1234", Bob wants
to use this to discover Alice's mesh record.
If Bob knows Alice's bank account number (IBAN), he wants to use this to
discover Alice's mesh record.

The choice of which naming to trust is given to the participant initiating
discovery (Bob). This way, Alice can register her mesh record with
facebook, twitter, gmail, t-mobile...

MSP: Operators of Naming Infrastructures:

There are tons of naming schemes in use out there and each of them under is
the control of custodians. Gmail for alice at gmail.com, the bank for my IBAN,
the telco operator for my number. Even facebook for my facebook account
(DNS, ...). We call these custodians OPERATORS of naming schemes.

The custodian of each legacy naming infrastructure shall be able to adhere
to the mesh network and earn money with providing onboarding and discovery
services.

The operator of Gmail can be paid for validating that alice is the
legitimate owner of alice at gmail.com.
The operator of Alice's bank account with IBAN "AD1400080001001234567890"
can provide a legitimate proof that Alice is the owner of that bank account.

MSP: Validators of Naming Schemes:

Beside operators of naming infrastructures, validators can be paid to
proceed with known validation schemes (even though less reliable than
operators based validation):

- A validator can check that Bob has read access to bob at gmail.com or
to +1-678-321-3454 by sending a challenge to those addresses and having Bob
provide that challenge.
- A validator can check that Bob has write access to bob at gmail.com or
to +1-678-321-3454 by having Bob send a given nonce to a provided address
using those addresses.
- A validator can check that Alice has read access to the bank account
with IBAN "AD1400080001001234567890" by transferring money to bank account
(with purpose code "challenge") and have Bob alice present that challenge.
- A validator can check that Alice has write access to the bank account
with IBAN "AD1400080001001234567890" by having alice transfer money to a
given bank account (providing a given purpose code "none")

Operator/Vendor Locking

I am not worried about operator locking because all names to record mapping
are registered in the discovery log (merkle tree). Migrating is also
simple. Bob can give up bob at gmail.com or to +1-678-321-3454 without any
fear. Bob simply has to have mapping invalidated in the discovery log.

Peer Validation of Naming Schemes (PeerPoP)

Beside relying on operators and validators for onboarding and discovery,
participants can use peer2peer validation schemes to prove association of
mesh records with given names. Alice's mesh client can wire money to Bob's
bank account and provide the given nonce to Bob's mesh client as a proof
the alice has write access to that bank account. This can be done as well
with phones, email, Whatsapp, ... We can call this Peer2Peer Proof of
Possession (PeerPoP).

Money is Spam Prevention

The best way of preventing spam in the mesh network is to have participants
pay for operations they initiate. Or have them sponsored by commercial
participants. A recipient of a message will always get paid for
receiving the message. The MSP of the recipient can also have a share of
the payment.

This is what we miss on today's email and telephone system. If i could get
paid for receiving an email or a spam call, i won't mind them!!!

Privacy
I am also worried about privacy when it comes to public discovery log. I am
not sure we can solve that problem. If mesh implements money based spam
protection, and mesh allows participants to define the price of a message
they receive, we will solve the pam problem and care less about having all
naming records in the publicly available discovery log.

I am not worried about social inclusion as the recipient can use an
acknowledge message to return money to the legitimate sender.

/Francis

On Sat, Sep 26, 2020 at 12:41 PM Phillip Hallam-Baker <phill at hallambaker.com>
wrote:

> On Sat, Sep 26, 2020 at 1:47 AM Richard Outerbridge <outer at interlog.com>
> wrote:
>
>> Maybe only if some chain also followed the number around through number
>> reassignments,
>> iotw if each number had its own chain of number reassignments?
>>
>
> Here is how I would see things going.
>
> First off, nobody uses telephone numbers for dialing any more. They are
> used to establish an initial connection and then get stored in a contacts
> list.
>
> Secondly, if you build on the legacy telephone infrastructure, you are
> going to end up finding yourself regulated under CALEA. Not good.
>
> So let us imagine that parallel to the Mesh naming system, there is a Mesh
> telephone number tracking system. I can register my telephone number and
> bind it to a Mesh account. And this is authenticated and periodically
> re-authenticated by means of a callback. Maybe the service tracks the SS7
> system to see if things have been reassigned.
>
> Alice has +1-617-666-1234 registered in this service and it binds to
> alice at service.
>
> So now lets imagine that Bob is using his Mesh enabled comms app to call
> Alice. She is not in her contacts, he dials the number on her business card
> +1-617-666-1234
>
> * Consult the telephone number registry, the name is there, use the Mesh
> VOIP protocol to establish an end to end secure voice call to alice at service.
>
> * (Optional) try other non telephone providers.
>
> * If not found, drop down to standard SIP based VOIP telephony (however
> that works) through her telephony provider. Since Alice doesn't know Bob
> (yet) this is likely to be a voicemail box because the legacy telephone
> system is so spammy these days it is dying and will soon be dead, dead,
> dead.
>
> The advantage of going through the Mesh first is of course we can then
> achieve end-to-end secure and have the ability to shift to a different
> modality (message, video) if desired. And since Alice doesn't know Bob in
> this use case, she can require him to perform a contact request first
> unless Bob has a credential from some group Alice has put in her accept
> policy.
>
> The way I see things, traditional telephone and SMTP email are dying
> because they are too spammy to live. And the only thing keeping them alive
> for now is the fact that they are the only open, interoperable game in
> town. If there is a viable spam free alternative that is open, it will
> start to acquire users and will be supported by a large number of ISPs etc.
> who realize that they are not going to establish themselves as the monopoly
> provider of the replacement system.
>
>
-- 
Francis Pouatcha
Technical Lead
adorsys GmbH & Co. KG
https:// <https://adorsys-platform.de/solutions/>www.adorsys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20200926/019a711f/attachment.htm>