
The GNU Name System IETF Draft - rurban
https://tools.ietf.org/id/draft-schanzen-gns-01.html
======
als0
> GNS is based on the principle of a petname system and builds on ideas from
> the Simple Distributed Security Infrastructure (SDSI), addressing a central
> issue with the decentralized mapping of secure identifiers to memorable
> names: namely the impossibility of providing a global, secure and memorable
> mapping without a trusted authority.

Great to see people learning from SDSI and SPKI, which have largely been
forgotten despite their achievements.

~~~
ryukafalz
Agreed. I've only recently been learning about capability and capability-like
systems like SPKI, and there are lots of great ideas there that haven't gotten
much attention since. It's refreshing to see them pop up in things like this!

------
joosters
The draft spec mentions DHT in several places long before it defines what
exactly it is (in section 4)

Perhaps the spec would be better if it added a table of definitions at the
top, just like it has a table of names for the cryptographic primitives.

~~~
jaekash
The draft has it's issues, but the draft mentions ECDSA also without ever
defining it and I'm sure I can find similar things in other accepted RFCs.

I think there is some domain knowledge that can be reasonably assumed when
writing documents.

------
eqvinox
Why would this be an IETF document when the GNUnet protocol itself isn't?

"This document does not specifiy the properties of the underlying distributed
hash table (DHT) which is required by any GNS implementation."

Okay... so...

~~~
jaekash
> Why would this be an IETF document when the GNUnet protocol itself isn't?

Nothing in the spec suggests it must run on GNUnet. This is almost like asking
why should IETF standardize JSON-schema when gRPC is not standardized. One
thing does not require the other or depend on the other.

> "This document does not specifiy the properties of the underlying
> distributed hash table (DHT) which is required by any GNS implementation."

Well they do specify the interfaces, why should they care about the
impliementation?

> GNS resource records are published in a distributed hash table (DHT). We
> assume that a DHT provides two functions: GET(key) and PUT(key,value).

> Okay... so...

So what?

~~~
eqvinox
> So what?

So, it's currently a disconnected lego brick hanging in the air. It serves no
purpose until other documents accompany it that specify how to use it either
for GNUnet, for IP, or something else. If there is more than one application
document coming, at least one should (IMHO) be submitted at the same time¹ in
order to aid review and understanding. If only one such application is
expected, they should probably be merged into the same document.

Particularly, if it's to be applied for non-GNUnet (e.g. IP), it does need to
say what underlying DHT is to be used. Otherwise it's not actually a naming
system but 10 naming systems – which is, er, rather useless.

¹: it doesn't need to progress or be finalized at the same time, but the
document should at least be published.

~~~
schanzen
This is not true. Please study, for example,
[https://tools.ietf.org/html/rfc6537](https://tools.ietf.org/html/rfc6537).

~~~
eqvinox
RFC6537 specifies an "upwards" (application direction) interface to HIP
(RFC5201). Through that it is fully wired into IPsec / Mobile IP use. The GNS
draft makes references to DNS but doesn't actually say how it would be used in
that relationship.

RFC6537 references OpenDHT as a "downwards" (wire direction) interface and
points to XML-RPC calls and expected behavior on that. The GNS draft simply
presumes the existence of a "DHT".

Maybe you could tell me which part of my comment is not true? I don't see what
your example is intended to illustrate...

[Edited to add:]

P.S.: please read the guidelines at
[https://www.ietf.org/standards/process/informational-vs-
expe...](https://www.ietf.org/standards/process/informational-vs-
experimental/) (section 3.)

GNS is very much something that can be "practiced" — or rather, it should be
possible to practice. I don't think it can with your draft. I suppose that
might be why you went for Informational rather than Experimental, but that
kinda misses the point: you _should_ be going for Experimental.

To walk through the guideline bulletpoints:

1\. GNS can be practiced. Or rather: should be. It's a protocol.

2\. If you want to push it through the IETF, you should probably open it to
changes. What's the point otherwise? The IETF is not a rubber-stamping
organization.

3\. I'm pretty sure you're not publishing this as "dropped, just for the
record"?

4\. "If the IETF may publish something based on this on the standards track
once we know how well this one works, it's Experimental." I feel that's
exactly your intent?

5\. Doesn't seem to apply. Maybe it should too?

All I'm saying is that your draft should be practice-able, but isn't, and I
think it should be.

~~~
schanzen
Your comment does not make sense because it fundamentally says that the spec
needs to define the DHT so that no 10 name systems exist. But that is simply
nonsense. If you implement a new DNS stub resolver that follows the record
wire formats but uses different root servers it will be effectively not the
"same" name system as vanilla DNS. It will have different records under names
and certainly different security properties. That is the whole point of hyper-
local root for DNS. I am simply implying that you are wrong in that we have to
specify the underlying layer. Anyone can (should be) able to use the spec an
implement it. It could be done on top of Bittorrent (not Kademlia as that is
the protocol, not the network!), IPFS (the DHT they use) or any other DHT.
With the respective implicatoins on security. It will still be conforming to
the spec.

------
brohee
Lots of people don't like the crypto construction used at all

[https://soatok.blog/2020/07/08/gnu-a-heuristic-for-bad-
crypt...](https://soatok.blog/2020/07/08/gnu-a-heuristic-for-bad-
cryptography/)

The non AEAD symmetric cipher is IMHO completely unjustifiable in 2020.

------
upofadown
They are baking the type of public key system (ECDSA) and a specific curve
(Curve25519) right into the standard?

So what happens if some sort of weakness is discovered in one of both of them?
The internet falls apart?

You need to define what is supposed to happen if your cryptography breaks.

~~~
schanzen
See 9.1.

If ECDSA or Curve25519 are broken (e.g. because of quantum crypto), we can
simply introduce a PKEY replacement (such as PKEY2) and migrate.

EDIT: However, point well taken. This needs more space in the draft and is
definitely a point to address.

~~~
upofadown
One perhaps obvious contingency is what to do if the key length has to get
longer.

------
Ericson2314
This is very much a draft, as it seems many important things (like the label
plaintext) is missing from grammars / packet diagrams.

~~~
tln
FIXME: ausdenken was wir da gerne haetten.

~~~
schanzen
Thanks, will be removed in -02 ;)

------
maverick74
FINALLY

