Subject: [Medup] GNU Name System draft

From: Christian Grothoff <[email-masked]>
Date: Mon, 27 Jul 2020 14:44:36 +0200

Dear all,

We'll be presenting our draft on the GNU Name System
(https://tools.ietf.org/id/draft-schanzen-gns-01.html)
at IETF 101 SECDISPATCH
(https://datatracker.ietf.org/doc/agenda-101-secdispatch/).

GNS might be a topic for MEDUP, so please join the discussion!

Thanks!

Christian

---

From: Christian Grothoff <[email-masked]>
Date: Mon, 27 Jul 2020 15:05:51 +0200

Eh, it is of course ITEF 108. Sorry for the bad link...
https://datatracker.ietf.org/meeting/108/session/secdispatch

---

From: Paul Wouters <[email-masked]>
Date: Mon, 27 Jul 2020 22:34:27 -0400 (EDT)

>> GNS might be a topic for MEDUP, so please join the discussion!

I read the draft. I am confused about a few aspects.

The first is similar to other schemes suggested that replace the central
authority with proof of ownership of a private key. If the private key
is lost or compromised, the entire GNS name is at risk of being lost or
taken over. Similarly, if a court would rule the transfer of a GNS name
(say from a rogue sysadmin of the company) than there is no entity that
can execute this. For namespaces that might have millions of dollars
of value behind it, that is really a no starter. Image that someone at
Coca Cola screws up and now no one controls cocacola.com anymore and it
is dead.

In this case, I also did not quite understand how a change of crypto
by GNS apparently creates a new namespace with a fresh new "first come,
first serve" run ?

That is, a lot of this ends up depending not on a specification published
by an RFC, but by GNS clients that either implement a GNS variant or
not. This typically leads to newer variants being impossible to launch. We
had this problem ourselves with DNS itself with the IN CLASS.

I'm also not sure how the mapping works between a memorable name in the new
namespace and the conversion internally to a name that contains the
public key representation.

I also feel there is a fake TLD lookup involved somewhere to map the
name onto GNS instead of DNS, so that would be an entire other problem
that has sadly been discussed many times before without a resolution
by the IETF or ICANN.

I think the document could be be improved by giving an overview of the
entire mechanism before going into the packet formats and record
formats. I also found the illustrations a bit confusing, as they did
not use the regular IETF notation.

The introduction also sounded a bit political under the guise of
technical arguments. It suggests DNS can be taken over by a nation
state. That the "global availability" or "integrity" can be attacked.
These are are weak argumens that seem meant to obfuscate that the real
goal is privacy and censorship resistance.

DNSSEC already provides integrity.

DoT and DoH are about to add some privacy to DNS, although streams of
queries could still lead to identifcation of source and data.

DNS via DoH is working on censorship resistance.

This leads me personally to not be very convinced of the added value
here. There are also disadvantages for using a non-DNS system for
naming to avoid state censorship. Once you install such a system as
GNS, you can no longer claim you were never trying to circumvent the
censors. Using GNS could simply become a crime. Having a DoT/DoH
stock and standard DNS implementation that _can_ be used for
circumvention would not have this issue.

Then there is the issue of creating a new namespace. When ICANN
did this, it created a lot of problems. Such as people feeling
forced to register their name/trademark in the new space or else
weaken their trademark.

Lastly, why go through this much effort for making only a name space
censorship resistant? Why not just all the traffic? Eg what does this
add to something like tor?

So, all in all, I'm not very convinced this specification, or any
other "decentralized" naming system, will solve any realworld
problem.

Paul

---

From: Christian Grothoff <[email-masked]>
Date: Tue, 28 Jul 2020 13:55:35 +0200

> I read the draft. I am confused about a few aspects.

Yes. Very much so.

> taken over.

Not exactly. If you loose a private key, you loose the corresponding TLD
(something like 8PF4803Z4M2Q1PVW84VCQSQNTWB5WVJN984S3YGHEE9JCNVXEMHG)
forever. In fact, I just created and deleted that key. So say goodbye
forever to that TLD (or good luck with brute force recovery).

But memorable names are established by humans and any name can always be
re-assigned to another key by those human users.

You may be confused and thinking there is a blockchain with some
'eternal' registration mechanism, but there is not.

> Similarly, if a court would rule the transfer of a GNS name
> can execute this.> For namespaces that might have millions of dollars

That is false. If there was a zone .com. in GNS, and it pointed to a key
for cocacola.com, then the zone administrator of .com can freely change
the delegation to a new key under the control of a non-rouge sysadmin.

And to go one level up, if Verisign lost its DNSKEY key for '.com', what
would it do today? It would have to go to ICANN and provision a fresh
key. Combine this with a hyperlocal DNS root, and the recovery process
of DNSSEC for '.com' mirrors that of TLD recovery for GNS (modulo GNS
not having stub resolvers, but ONLY full recursive resolvers with
hyperlocal roots on all clients).

> by GNS apparently creates a new namespace with a fresh new "first come,

A change of crypto by GNS would create a new namespace. We will need to
clarify how this is done in the spec.

> had this problem ourselves with DNS itself with the IN CLASS.

The IN CLASS problem is fundamentally a different, because here users
cannot specify a different class to be used. So sure, this is related in
that users cannot specify whether to use GNS or DNS -- our software just
overrides / takes precedence over DNS resolution if installed --, but
once you do use GNS, changing the crypto is not something users need to
even be told about. However, we do indeed not really solve the problem
of migrating to yet another name system (say ENS). But that is a
usability problem created by IETF's historic decisions (see RFC 8244),
so we don't own that one.

> public key representation.

The first mapping (say .com ->
8PF4803Z4M2Q1PVW84VCQSQNTWB5WVJN984S3YGHEE9JCNVXEMHG) is hyper-local on
the user's system. Delegations use PKEY records (see resolution logic in
the spec).

> that has sadly been discussed many times before without a resolution

Not sure if I would call it a 'fake TLD'. As IETF rejected our proposal
for a TLD of ".gnu", we don't use a special-use TLD anymore, but really
simply override the full DNS namespace. I've done test-installations
where I migrated '.fr' to GNS and then called my GNS zone ".de" and
could then lookup zones like "lemonde.de" (basically stealing ".de" from
DENIC per hyper-local configuration entry). So there is no more
special-use TLD, the user simply decides per local configuration which
domains (including "foo.bar.baz", or even "." so not just TLDs) to
delegate to GNS. The rest is then passed on to DNS.

> not use the regular IETF notation.

We appreciate specific suggestions for improvements.

> goal is privacy and censorship resistance.

Global availability is a technical characterization of the political
goal of censorship resistance.

> DNSSEC already provides integrity.

Not end-to-end.

> queries could still lead to identifcation of source and data.

DoH is exposes DNS queries to a US business that is easily compelled to
exfiltrate the data to a global terror syndicate.

> circumvention would not have this issue.

DoH is quite explicitly designed to allow users to break Swiss laws and
thus its use could easily be made a crime in Switzerland as well. Good
luck arguing in court that DoH is "standard DNS implementation".

> forced to register their name/trademark in the new space or else

GNUnet e.V. looks forward to collecting millions in registration fees
for the hyper-local default root zone. The GNU project has been
underfunded forever. So if you are right, we'll be happy to change that.

> add to something like tor?

When the German police took down "piratenpartei.de" (a moderate, legal
German political party) during an election (ab)using established "legal"
DNS censorship procedures, how would Tor help users access the site?

> other "decentralized" naming system, will solve any realworld

You are thinking way to narrow in terms of current DNS use-cases. I
suggest you review

https://git.gnunet.org/bibliography.git/plain/docs/dasein10.pdf

for some additional use-cases of GNS. We already used it for access to
sensitive health data, sharing (private) sensor data, and for
privacy-preserving attribute-based credentials / decentralized
self-sovereign OIDC).

I hope this clarifies things a bit.

Best,

Christian