The GNU Name System IETF Draft(tools.ietf.org)
tools.ietf.org
The GNU Name System IETF Draft
https://tools.ietf.org/id/draft-schanzen-gns-01.html
33 comments
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.
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.
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.
I think there is some domain knowledge that can be reasonably assumed when writing documents.
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...
"This document does not specifiy the properties of the underlying distributed hash table (DHT) which is required by any GNS implementation."
Okay... so...
> 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?
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?
> 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.
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.
"lego brick" ? No, it's actually the most important pillars of the digital future (GNS, reclaim:id, Taler, Secushare... all based on gnunet)
This is not true. Please study, for example, https://tools.ietf.org/html/rfc6537.
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... (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.
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... (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.
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.
[deleted]
>> "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.
> 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.
Yes, sure.
But that's fine - everyone who wants to have their GNS can design their own DHT. It's still outside of the spec. (Which makes a lot of sense to me.)
> The choice of DHT typically has protocolar implications, such as the use of XOR metric in Kademlia, or the bootstrap algorithm.
> Furthermore, different DHTs have distinct properties, including provisions for fault tolerance, resource recovery, latency bounds, and byzantine tolerance, which here seems like a concern.
What in the RFC is dependent or contingent on those? from what I read in it none of those properties affect what is specified in the draft.
> All nodes must use the same DHT. As a result, this cannot be implemented without knowing the particular DHT in use.
Not according to the draft. Sure, if a zone uses a specific DHT and then other nodes not using the same DHT they won't be able to resolve addresses from that zones, but everything in this draft would still be valid.
> Furthermore, different DHTs have distinct properties, including provisions for fault tolerance, resource recovery, latency bounds, and byzantine tolerance, which here seems like a concern.
What in the RFC is dependent or contingent on those? from what I read in it none of those properties affect what is specified in the draft.
> All nodes must use the same DHT. As a result, this cannot be implemented without knowing the particular DHT in use.
Not according to the draft. Sure, if a zone uses a specific DHT and then other nodes not using the same DHT they won't be able to resolve addresses from that zones, but everything in this draft would still be valid.
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.
> 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
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
> > 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]
In practice, that's not been true for many years. The process was recently clarified: "IETF Stream Documents Require IETF Rough Consensus" https://www.rfc-editor.org/rfc/rfc8789.html
In practice, that's not been true for many years. The process was recently clarified: "IETF Stream Documents Require IETF Rough Consensus" https://www.rfc-editor.org/rfc/rfc8789.html
Oh, Thanks for the pointer! "published: June 2020" — no kidding with the "recently" :)
> Not really. RFCs in the Informational category don't need consensus.
They don't, but they also need to not conflict with any IETF activity:
"4.2.3 Procedures for Experimental and Informational RFCs
[...]
To ensure that the non-standards track Experimental and Informational designations are not misused to circumvent the Internet Standards Process, the IESG and the RFC Editor have agreed that the RFC Editor will refer to the IESG any document submitted for Experimental or Informational publication which, in the opinion of the RFC Editor, may be related to work being done, or expected to be done, within the IETF community." [https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2.3]
Apart from that, it's unclear to me what the document is actually trying to do [cf. my comment in https://news.ycombinator.com/item?id=23769617]
They don't, but they also need to not conflict with any IETF activity:
"4.2.3 Procedures for Experimental and Informational RFCs
[...]
To ensure that the non-standards track Experimental and Informational designations are not misused to circumvent the Internet Standards Process, the IESG and the RFC Editor have agreed that the RFC Editor will refer to the IESG any document submitted for Experimental or Informational publication which, in the opinion of the RFC Editor, may be related to work being done, or expected to be done, within the IETF community." [https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2.3]
Apart from that, it's unclear to me what the document is actually trying to do [cf. my comment in https://news.ycombinator.com/item?id=23769617]
The IESG will request non-publication of Individual Submission Editor (ISE) stream RFCs when they would cause harm. Something like GNS would almost certainly be allowed.
Nothing you wrote contradicts what GP wrote. (Your text, other than the first two words, also appears correct but doesn’t address GP’s argument.)
GP claims getting consensus is hard. You argue that it’s not needed. Correct, but tangential.
GP claims getting consensus is hard. You argue that it’s not needed. Correct, but tangential.
Gp clearly implies getting consensus would be the hard part for this ID to become an “IETF document”. You can strip all context and argue that every single statement is correct in isolation, but that’s not how communication works.
This pointless bickering also adds zero new info, so I’ll stop here.
This pointless bickering also adds zero new info, so I’ll stop here.
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.
https://soatok.blog/2020/07/08/gnu-a-heuristic-for-bad-crypt...
The non AEAD symmetric cipher is IMHO completely unjustifiable in 2020.
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.
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.
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.
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.
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.
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.
One perhaps obvious contingency is what to do if the key length has to get longer.
This is very much a draft, as it seems many important things (like the label plaintext) is missing from grammars / packet diagrams.
FINALLY
Great to see people learning from SDSI and SPKI, which have largely been forgotten despite their achievements.