Subject: [Secdispatch] One way sequence based naming

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 2 Aug 2020 14:48:38 -0400

I was doing HOPE and IETF in parallel. I support doing research work on new
naming schemes but I think we should limit I*TF input to research at this
stage.

Among the naming infrastructures that currently interest me:

* Routing: AS to IP Address block mapping

* Trusted discovery: Validated real world names -> Internet Services

* Portable accounts: Text identifiers -> key fingerprint

When looking at these issues, the first concern of many is of course the
risk that their own business model might be threatened. That is why I never
come to IETF for permission to do anything. Of course, the DNS is not going
to disappear overnight. Nor is the RPKI. But that doesn't mean that these
are the only naming systems that can ever exist on the Internet. It will be
a very long time before telephone numbers disappear entirely.

The gap in the registry market at present is in portable account
identifiers. I am [email-masked] and [email-masked]. The first
name exists only as long as gmail.com wills it, I am at their mercy.
hallambaker.com belongs to me, I have autonomy but that costs me $10/year
and the name doesn't actually belong to me, I merely have use of it.

I believe that there is value in a personal identifier registry offering
irrevocable identifiers. So being a Bond/TNG fan and wishing to reclaim the
id from a bigot, I have the handle Q, thus:

q:
   udf:  MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4
   service: cryptomesh.com
   dns:
       ipv4:10.1.2.3
       suffix: .not-an-icann-domain

I will get back to the interpretation later. For now, the point is that
this allows me to resolve names of the form @q (to message me) or @q.www
and these names are fixed in all time and do not depend on ICANN's DNS
product in any shape or form.

Having worked on DNS, WebPKI, etc, I think I have some understanding of
where the costs come from. The DNS is expensive to run because the DNS
protocol supports three very different types of service in a single
protocol and that means that the infrastructure that supports discovery of
the microsoft.com name server has to meet the low latency and rapid up date
requirements of discovery of a service www.microsoft.com.

I am pretty sure the world would manage just fine if the rules for updating
domains in .com were that updates take 60 seconds to process with a (small)
charge for each update.

These constraints allow a zone file to be represented as an authenticated
append only sequence. Updates are consolidated into blocks with a new block
being added once a minute. Authentication is provided by a Merkle tree over
the sequence of blocks meaning that the cryptographic overhead of
authenticating the service is fixed regardless of load.

If the number of updates were limited to an average of one per domain per
year, the entire .com domain would generate less than 100GB of data per
year. Every recursive resolver operated at the ISP level can keep a
complete copy.

Names do not expire and all costs of the registry depend only on the number
of updates. The ruinous costs of running core DNS have been avoided because
the registry operator is insulated from DDoS attacks.

Open Source software works because the marginal cost of providing service
is essentially nil. Open services are more difficult because 5 billion
users times a small cost is a large cost.

Based on my experience, I expect running such a registry would cost less
than $250,000/yr + $0.01 per transaction. So the registry would break-even
at 2.5 million registrations a year at $0.10 each. I am not going to go
into the business model further here. The point is merely to show that this
doesn't depend on me continuing to fund the Mesh Foundation.

When I started designing this system, my goal was limited to providing a
registry that allows Mesh messaging users to interact using names that give
them personal autonomy. So I could use the free service and be
[email-masked] or I could pay cryptomesh for their paid premium service
and they would register @q for me. And now I can change my mesh service
provider any time I like and nobody needs to change their contact.

What this gives here is a human intelligible, life-long permanent
identifier that people could use to contact others for Mesh Messaging that
has a strong binding to a signature verification key.

The same approach can be applied to services to make them censorship proof:

I have my personal Web site at https://hallambaker.com/. We can convert
that into a domain name as follows:

To resolve @q.www

1) @q.www + q.not-an-icann-domain -> www.q.not-an-icann-domain
2) Resolve www.q.not-an-icann-domain using the authoritative DNS service at
10.1.2.3

So all we need to make this approach compatible with existing Web Browsers
is a way of encoding @q.www in some reserved partition of the DNS space:

http://www.q.mesh.arpa/

This can all be fixed up to provide a seamless experience for users of
legacy browsers. Basically, mesh.arpa would have to be delegated to some
organization that provides a DNS resolver that provides the necessary
redirect.

But the objective here would be for browsers to use a resolution protocol
that performs validation of that chain against the trust root for @q.

Oh and as for anonymity. Threshold key generation provides a simple means
of using one signature key to manage any number of domains using a
different key for each. People already do this with bitcoin wallets. So I
can run @q and @phb without disclosing that they are both me.

The chief cost of running such a registry would be the inevitable trademark
issues. But these can also be handled on a fee per transaction basis
starting with a significant fee for registering a claim. If someone is
paying a lawyer $600/hr to police a trademark, they can reimburse the
registry for the cost of processing claims. That is a separate can of worms
to the technical side of things.