The GNU Name System IETF Draft

https://tools.ietf.org/id/draft-schanzen-gns-01.html

by rurban • 6 years ago

114 32 6 years ago

tools.ietf.org

eqvinox5• 6 years ago

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...

jaekash3• 6 years ago

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?

espadrine• 6 years ago

> "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?

The choice of DHT typically has protocolar implications, such as the use of XOR metric in Kademlia, or the bootstrap algorithm.

All nodes must use the same DHT. As a result, this cannot be implemented without knowing the particular DHT in use.

Furthermore, different DHTs have distinct properties, including provisions for fault tolerance, resource recovery, latency bounds, and byzantine tolerance, which here seems like a concern.

eqvinox5• 6 years ago

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.

mhandley• 6 years ago

It's not an IETF document - it's an independently submitted Internet draft that hasn't been adopted by any IETF working group at this stage. Anyone can write an internet draft. Getting concensus on it is the hard part.

oefrha2• 6 years ago

Anyone can write an internet draft. Getting concensus on it is the hard part.

Not really. RFCs in the Informational category don't need consensus:[1]

An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see section 4.2.3).

Example: RFC 2448 AT&T's Error Resilient Video Transmission Technique.[2]

This particular ID is informational rather than on the standards track.

[1] https://www.ietf.org/standards/process/informational-vs-expe...

[2] https://tools.ietf.org/html/rfc2448

als0• 6 years ago

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• 6 years ago

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• 6 years ago

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.

jaekash3• 6 years ago

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.

maverick74• 6 years ago

FINALLY

Ericson2314• 6 years ago

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

tln• 6 years ago

FIXME: ausdenken was wir da gerne haetten.

schanzen5• 6 years ago

Thanks, will be removed in -02 ;)

schanzen5• 6 years ago

That is actually a feature (zone privacy). The label should not be in plaintext anywhere.

upofadown2• 6 years ago

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.

schanzen5• 6 years ago

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.

upofadown2• 6 years ago

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

goalieca• 6 years ago

A weakness will not come in the form of "it's suddenly broken". It will be a slow decline of worsening performance. Even quantum computing will be moving forward with a gradual rate of growth in Qubits.

At some point during this transition, it will break and they will have to transition. It will not be hard to create an new RFC for that task. It will be hard to replace all of the implementations in the field. We are getting better at this with our experiences in TLS but it is still somewhat painful.

Crypto agility can be really nice but it can also be messy. Sometimes it's best to be opinionated and sometimes it's easier to just be flexible.

brohee• 6 years ago

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

https://soatok.blog/2020/07/08/gnu-a-heuristic-for-bad-crypt...

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

The GNU Name System IETF Draft

Related Stories