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

[Phillip Hallam-Baker]

I have restarted work on the Mesh after a short holiday. The revised
architecture document should be ready in a fortnight. There is one very
critical piece of infrastructure I haven't mentioned yet, the naming
system. I suggest that people read the whole post before reacting rather
than assuming that I am the usual sort of capitalist despot.

The Mesh is a Threshold Key Infrastructure which is basically a PKI but
making use of the fact that we can split private keys into shares etc. I
have tried to minimize the need for a service element and to minimize the
degree to which the user needs to trust the service element. But the Mesh
incorporates an asynchronous messaging capability which necessarily
requires some sort of service to act as a dropbox to which messages can be
posted for later collection. I call this a Mesh Service Provider.

Alice and Bob are probably capable of running their own MSPs, they have
been doing crypto together for over 40 years after all. But most users
won't. They are going to have to outsource their MSP provision to some
third party. And I think that is completely OK, most of us outsource SMTP
email service these days. What is not OK is the SMTP model where the email
address is tied to the service provider so that changing email providers
incurs an enormous switching cost.

The current corporate model for Internet services is to try to make
everything sticky. I don't want that even though one of the businesses I
have started is going to be an MSP. The Mesh is all about putting the user
in control. User's can't be in control if they are chained to the service
provider.

So what we need is a simple registry that provides service discovery. The
very simplest form of registry would be to map a UDF of a Mesh fingerprint
to the service provider. So mb2gk-6duf5-ygyyl-jny5e -> alice at example.com.
And we could have a few of those. But that wouldn't last long because users
would much much rather just be something like @alice.


So I don't want Alice's address to be alice at example.com. I want her to
be @Alice. And I want her to be able to use that same account and address
at cryptomesh (my MSP) or Comcast or Google, or whoever. This makes it very
easy for Alice to be her own MSP if she chooses, it isn't a lifetime
commitment.

This is the point at which someone fisking the thread will write, 'but
Phill, you don't understand, running a naming system is really hard, just
look at ICANN'. Yeah, like I wasn't Principal Scientist of VeriSign for a
dozen years when we bought Network Solutions. This stuff is difficult and I
have been lucky in the past. But meeting Tim BL was luck, joining VRSN and
creating the WebPKI was not.

So if @bob wants to send a message to @alice, his MSP will lookup @alice in
the registry, discover that it is currently serviced by example.com and
send the message there.

This is a difficult problem if you decide to make it so. It really doesn't
cost $250,000 to decide if someone should have a TLD. That is pure rent
seeking. And no, I don't want to enter into discussions of why that is OK
or why we should embrace an organization charging $250,000 for a
registration as the operator of the successor to the WebPKI where CAs
charge a few hundred dollars a year. The important point we will come back
to later is that while the registry I describe would cost almost (but not
quite) nothing to run, it would potentially generate a vast amount of
value. People will be willing to pay significant sums for names such
as @london etc, there will be trademark issues with @microsoft, etc. etc.
And again, the only reason I am stating the blitheringly obvious here is
the alternative is a series of comments of the form 'Phill, you ignorant
slut'.


OK so the simplest record for alice would be something like:

alice :
    udf: mb2gk-6duf5-ygyyl-jny5e
    service: example.com
    registration: initial

And we put this all in an append only log authenticated by a Merkle Tree
and sign it once a minute. But unlike in the DNS system, the registry does
not provide a query service. Instead, MSPs maintain a local copy of the
registry of names and use that to respond to queries from their users.

Getting rid of the registry query service immediately removes 99% of the
cost of running the registry. It also means the system is inherently
failsafe. The worst that can happen if the registry is completely destroyed
is that the ability to post updates will be lost. A DDoS attack that takes
out the Comcast MNS service is not going to take out Verizon. The fact that
attacks cannot cause a global outage will greatly reduce the incentive. And
since an attack on Comcast can only come from Comcast customers they are in
a much better position to defend themselves.

Since we have a DDoS resistant infrastructure, why not use it to publish
delegations for DNS services as well?

comcast
    udf: MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4
    dns: 68.87.72.244
    dns: 69.252.250.103

ICANN world DNS can go down now and we can still reach @alice if her MSP is
comcast. Ain't that interesting?


At which point we should better think about the trustworthiness of the
entries. Aren't we putting a lot of trust in the registry?

The simplest record is not the best one because we want to have
authentication etc. etc. And so we are actually going to maintain two
separate logs. One of which contains the data we want to query, the other
of which contains the proofs.

Every change made to a record in the registry must be supported by an
assertion signed by the name holder.

The registry signs both append only logs once a minute. Validating MSPs
download both logs and check that every entry added to the log is supported
by proof. If everything is OK, the validating MSP sends a token back to the
registry saying 'I checked the log up to this point in time' and this is
entered into the registry log.

The net effect of this scheme is that as far as each MSP is concerned, they
are the root of trust for the append only logs: Any defection by the
registry will be detected. It is not possible for any of the parties to
defect without their defection being visible to all unless they all
collude. So we get the Blockchain type effect of preventing rollback but
with a 1 minute period instead of ~10 and without the need for proof of
waste.


So now, when  Bob sends that message to @alice he can be really sure it is
going to the right place, is end to end secure, etc. The only reason there
might be an issue is if the name has been reassigned because of a trademark
issue.

As a practical matter, I think it is essential that a naming system meet
the reasonable expectations of the users and that expectation is
that @microsoft goes to Microsoft corporation not some scammy namegrabber.
But @prince certainly doesn't go to Prince Sports, it goes to the artist's
estate. So some legal and UI issues there. I think it fine for names to be
reassigned provided that nobody USING the original name is affected and
that the reassignment is completely visible. So if @wikileaks is reassigned
to @fbi, anyone using the name is warned.

There is also an IoT play here, what if we want to send a message to
Alice's coffee pot? Well that is coffepot at alice.

We can represent these names in the DNS by defining our own TLD. No, I do
not feel inclined to pay ICANN's rent. One of the features of the Mesh is
provisioning network configuration information. So we can tell connected
devices which DNS service to use and that can map @alice to alice.mm--
which is not a valid TLD ICANN can assign.

Oh look, we have a new bit of censorship resistant technology. All she
needs is an authoritative DNS service and Alice can publish her stuff at
https://www.alice.mm--/ and that will be stable regardless of what ICANN
does. And her coffee pot can offer status info at
https://coffeepot.alice.mm--/ under a certificate that is signed under the
root of trust mb2gk-6duf5-ygyyl-jny5e.


No, I am not putting the CAs out of business with this. But I am
eliminating the need for LetsEncrypt and NSA corrupted botches like
DANE/TLSA. This will replace DV certs over time but the need for EV will be
just as important because creating a trust relationship requires a source
of accountability. And besides that, the Mesh creates more interesting
opportunities for CAs as Mesh applications will present logotype
information to the user.


OK so what about the business model for the registry? I expect this to cost
about $2 million a year to run it properly (no I am not spending that on
the prototype). We could go round with a begging bowl but look where that
got us with the NSF.

I think it much better just to charge for the names. But the incremental
cost of servicing a name is close to $0 and the cost of maintaining a name
IS $0.000000/year. There is no need for renewal fees. Names are for life
(unless sold or reassigned).

So one business model would be to charge $0.10 for a name with up to 50
change of service registrations included. Which is fine and the model I
would like to go with for names of 8 characters or more.

But why leave money on the table? My problem with the ICANN model isn't
just that they are corrupt rent seekers buying themselves bigger yachts, it
is the fact that (almost) none of the money ends up going to people who are
contributing to the development of Internet technology. It is just absorbed
by a clique of rent seekers and lawyers.

So what if we charged more for the shorter names that are going to be in
high demand and used the revenues to fund development of new Mesh
technology? The charges would increase exponentially as the name became
shorter. $100 for a 7 letter name, $1,000 for six, all the way up to $10
million for single letter names.

This approach has the important advantage of creating a disincentive for
namegrabers. Nobody is going to spend the $100,000 needed to namegrab @ibm
knowing that it will be reassigned.


The Mesh is a binary prospect. I don't think it can be a modest success.
Either it succeeds on global scale or not at all. So the registry is
potentially worth of the order of a VeriSign Inc. And so the only way that
it can possibly be allowed to succeed is as a form of public goods. Which
is fine, its not like I personally need the cash (and I will have the MSP
to unload). The only thing that can be done with wealth on that scale is to
hoard it (pointless), give it away or spend it on parties. What I propose
to do here is essentially short circuit the process so that the registry is
run by the Mesh foundation which spends a large proportion of it supporting
the developer community with consulting contracts, salaries and conferences
in really nice places. Think of it as the equivalent of making club in the
sales dept.

I see this as a win-win-win for everyone apart from (some of) the
incumbents.

Right now the IoT space is being dominated by five major players all trying
to establish themselves as the monopolist. And at least two of those are
starting to realize that the eventual monopolist isn't going to be them.
The Mesh provides an open playing field.


So in case the point of this message is not clear, I think I am close to
done with the design of the Mesh. I am going to need a vast number of
people to deploy it, many of whom are here. I don't have the funds to hire
everyone on contract but if we are successful there should be a foundation
that has the means to 'do the right thing' for everyone involved, including
the folk at Comodo who originally financed this work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20200922/036890fe/attachment.htm>