commit 841739521c57e7259b0913586ff146424aafdc9a
parent e3dd5e32dbf1894395fb59230ac2ca04b3fd4d71
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Mon, 20 Dec 2021 01:58:56 +0100
use storage instead of DHT
Diffstat:
1 file changed, 30 insertions(+), 28 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -138,9 +138,9 @@
This document defines the normative wire format of resource records, resolution processes,
cryptographic routines and security considerations for use by implementors.
In general any API which allows storing a value under a key and retrieving
- a value from the key can be used by an implementation for record storage.
- It is expected that a GNS implementation is using a distributed hash
- table (DHT).
+ a value from the key can be used by an implementation for record storage.
+ It is expected that a GNS implementation is using a distributed hash
+ table (DHT).
Specification of such a DHT is out of scope of this document but
possible existing implementations include <xref target="RFC7363" />
<xref target="Kademlia" />, <xref target="R5N" /> or <xref target="Ipfs" />.
@@ -169,7 +169,7 @@
where "d" is the private key and "zk" the corresponding public key
in the public key cipher identified by the "ztype".
The contents of a zone are cryptographically signed before
- being published in a distributed hash table (DHT).
+ being published.
Records are grouped by their label, and encrypted (<xref target="recordencryption"/>)
using an encryption key derived from the label and the zone public key.
Instead of the zone private key "d", the signature MUST
@@ -342,7 +342,7 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
"nonce" and "expiration".
A deterministic encryption scheme is
required to improve performance by leveraging caching features
- of DHTs.
+ of underlying storages, in particular DHTs.
</dd>
<dt>Sign(d',bdata) -> sig</dt>
<dd>
@@ -464,14 +464,15 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
If this flag is set, this record should be ignored by resolvers unless all (other)
records of the same record type have expired. Used to allow zone publishers to
facilitate good performance when records change by allowing them to put future
- values of records into the DHT. This way, future values can propagate and may be
+ values of records into the storage.
+ This way, future values can propagate and may be
cached before the transition becomes active.
</dd>
<dt>EXPREL</dt>
<dd>
The expiration time value of the record is a relative time (still in microseconds)
and not an absolute time. This flag should never be encountered by a resolver
- for records obtained from the DHT, but might be present when a resolver looks up
+ for records obtained from the storage, but might be present when a resolver looks up
private records of a zone hosted locally.
</dd>
<dt>
@@ -482,13 +483,13 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
other records. This flag indicates that this record is not explicitly
managed alongside the other records under the respective name but
may be useful for the application. This flag should only be encountered
- by a resolver for records obtained from the DHT.
+ by a resolver for records obtained from the storage.
</dd>
<dt>PRIVATE</dt>
<dd>
This is a private record of this peer and it should thus not be
- published in the DHT. Thus, this flag should never be encountered by
- a resolver for records obtained from the DHT.
+ published. Thus, this flag should never be encountered by
+ a resolver for records obtained from the storage.
Private records should still be considered just like
regular records when resolving labels in local zones.
</dd>
@@ -1118,14 +1119,14 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
We assume that a storage API provides two functions: GET(key) and PUT(key,value).
In GNS, resource records are grouped by their respective labels,
encrypted and published together in a single resource records block
- (RRBLOCK) in the DHT under a key "q": PUT(q, RRBLOCK).
+ (RRBLOCK) in the storage under a key "q": PUT(q, RRBLOCK).
The key "q" which is derived from the zone key "zk" and the respective
"label" of the contained records.
</t>
<section anchor="blinding" numbered="true" toc="default">
- <name>DHT Key Derivations</name>
+ <name>Storage Key Derivations</name>
<t>
- Given a label, the DHT key "q" is derived as follows:
+ Given a label, the storage key "q" is derived as follows:
</t>
<artwork name="" type="" align="left" alt=""><