commit 67b27a4f6a60fab903f5789a991261490b3f901b
parent 883e822ff2378065833c8b21c9739452d3c13827
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Mon, 31 Jan 2022 16:43:06 +0100
-misc minor edits
Diffstat:
1 file changed, 25 insertions(+), 17 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -197,10 +197,10 @@
<dd>
The rightmost label in a GNS name is a GNS Top-Level Domain (TLD).
Unlike DNS Top-Level Domains (defined in <xref target="RFC8499"/>),
- GNS does not use a root zone as such. Instead,
+ GNS does not expect all users to use the same global root zone. Instead,
with the exception of Zone Top-Level Domains (see below),
- GNS TLDs are part of the configuration of the local resolver
- (see <xref target="governance"/>) and may not be globally unique.
+ GNS TLDs are typically part of the configuration of the local resolver
+ (see <xref target="governance"/>), and may thus not be globally unique.
</dd>
<dt>Zone</dt>
<dd>
@@ -255,13 +255,17 @@
Zones are uniquely identified by a zone key.
Zone contents are signed using blinded private keys and
encrypted using derived secret keys.
- The zone type determines the respectice set of cryptographic functions.
+ The zone type determines the respective set of cryptographic operations
+ and the wire formats for encrypted data, public keys and signatures.
</t>
<t>
A zone can be populated with mappings from labels to resource records by
its owner (<xref target="rrecords"/>).
- Labels can be delegated to other zones using delegation records and in
- order to support (legacy) applications as well as facilitate the use
+ A label can be mapped to a delegation record which results in the
+ corresponding subdomain being delegated to another zone. Circular
+ delegations are explicitly allowed, including delegating a subdomain
+ to its immediate parent zone. In
+ order to support (legacy) applications as well as to facilitate the use
of petnames, GNS defines auxiliary record types in addition to
supporting traditional DNS records.
</t>
@@ -271,31 +275,35 @@
(<xref target="publish"/>).
In this process, unique zone identification is hidden from the network
through the use of key blinding.
- It allows the creation of signatures for zone contents
+ Key blinding allows the creation of signatures for zone contents
using a blinded public/private key pair.
This blinding is realized using a deterministic key
derivation from
- the original zone key and corresponding private key using record label values.
- Specifically, the zone owner can derive private keys for each record
+ the original zone key and corresponding private key using record label values
+ as blinding factors.
+ Specifically, the zone owner can derive blinded private keys for each record
set published under a label, and a
- resolver can derive the corresponding public keys.
+ resolver can derive the corresponding blinded public keys.
It is expected that GNS implementations use distributed or decentralized
storages such as distributed hash tables (DHT) in order to facilitate
- availability within a network without the need of servers.
+ availability within a network without the need for dedicated infrastructure.
Specification of such a distributed or decentralized storage is out of
- scope of this document but possible existing implementations include those
+ scope of this document, but possible existing implementations include those
based on <xref target="RFC7363" />, <xref target="Kademlia" /> or
<xref target="R5N" />.
</t>
<t>
Names in GNS are domain names as defined in <xref target="RFC8499"/>.
- Starting from a configurable root zone, names are resolved following zone
- delegations which are recursively queried from the storage (<xref target="resolution"/>).
+ Starting from a configurable root zone, names are resolved by following zone
+ delegations. For each label in a name, the recursive GNS resolver
+ fetches the respective record from the storage layer (<xref target="resolution"/>).
Without knowledge of the label values and the zone keys, the
- different derived keys are unlinkable both to the original key and to each
+ different derived keys are unlinkable both to the original zone key and to each
other.
- This prevents zone enumeration and requires knowledge
- of both the zone key and the label to confirm affiliation with a
+ This prevents zone enumeration (except via impractical online brute
+ force attacks) and requires knowledge
+ of both the zone key and the label to confirm affiliation of a
+ query or the corresponding encrypted record set with a
specific zone. At the same time, the blinded zone key provides
resolvers
with the ability to verify the integrity of the published information
