Re: [Medup] GNU Name System draft

[Paul Wouters <[e-mail]>]

On Mon, 27 Jul 2020, Christian Grothoff wrote:

> Eh, it is of course ITEF 108. Sorry for the bad link...
> https://datatracker.ietf.org/meeting/108/session/secdispatch
>
> On 7/27/20 2:44 PM, Christian Grothoff wrote:
>> 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!

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