[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: v19
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated: v19 |
|
Date: |
Tue, 21 Jun 2022 09:53:23 +0200 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a commit to branch master
in repository lsd0001.
The following commit(s) were added to refs/heads/master by this push:
new 06eb394 v19
06eb394 is described below
commit 06eb3946165481af20f1c8b9f8c2acec88587cb3
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Tue Jun 21 09:53:15 2022 +0200
v19
---
draft-schanzen-gns.xml | 259 +++++++++++++++++++++++++++----------------------
1 file changed, 145 insertions(+), 114 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 9a58ceb..ed50901 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -37,13 +37,13 @@
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
-<rfc xmlns:xi="http://www.w3.org/2001/XInclude"; category="info"
docName="draft-schanzen-gns-18" ipr="trust200902" obsoletes="" updates=""
submissionType="IETF" xml:lang="en" version="3">
+<rfc xmlns:xi="http://www.w3.org/2001/XInclude"; category="info"
docName="draft-schanzen-gns-19" ipr="trust200902" obsoletes="" updates=""
submissionType="IETF" xml:lang="en" version="3">
<!-- xml2rfc v2v3 conversion 2.26.0 -->
<front>
<title abbrev="The GNU Name System">
The GNU Name System
</title>
- <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-18"/>
+ <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-19"/>
<author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach">
<organization>Fraunhofer AISEC</organization>
<address>
@@ -335,111 +335,142 @@
</section>
<section anchor="overview" numbered="true" toc="default">
<name>Overview</name>
- <t>
- GNS exhibits the three properties of a petname system:
- </t>
- <ol>
- <li>
- It provides global names through the concept of zone top-level
- domains (zTLDs). As zones can be uniquely identified by their zone key
- and are statistically unqiue, GNS names with a zTLD suffix are also
- globally unique.
- </li>
- <li>
- It provides memorable or "human-readable" names by enabling users to
- configure local mappings from nicknames to zones.
- Zone owners can publish their mappings
- in order to enable namespace delegation and facilitate resolution of
- memorable names.
- </li>
- <li>
- It provides secure mapping from names to records as zone contents
- are signed using blinded private keys and encrypted using derived
- secret keys.
- </li>
- </ol>
- <t>
- In GNS, any user can create and manage one or more zones
- (<xref target="zones"/>) as part of a zone master implementation.
- The zone type determines the respective set of cryptographic operations
- and the wire formats for encrypted data, public keys and signatures.
- A zone can be populated with mappings from labels to resource records by
- its owner (<xref target="rrecords"/>).
- 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 existing DNS records.
- </t>
- <t>
- Zone contents are encrypted and signed
- before being published in a key-value storage (<xref target="publish"/>)
- as illustrated in <xref target="figure_arch_publish"/>.
- In this process, unique zone identification is hidden from the network
- through the use of key blinding.
- 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
- 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 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 for dedicated
infrastructure.
- Specification of such a distributed or decentralized storage is out of
- scope of this document, but possible existing implementations include
those
- based on <xref target="RFC7363" />, <xref target="Kademlia" /> or
- <xref target="R5N" />.
- </t>
- <figure anchor="figure_arch_publish" title="An example diagram of two
hosts publishing GNS zones.">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- Local Host | Remote | Remote Host
- | Storage |
- | |
- | +---------+ |
- | / /| |
- Publish | +---------+ | | Publish
- +---------+ Records | | | | | Records +---------+
- | Zone |----------|->| Record | |<-|----------| Zone |
- | Master | | | Storage | | | | Master |
- +---------+ | | |/ | +---------+
- A | +---------+ | A
- | | | |
- +---------+ | | +---------+
- / | /| | | / | /|
- +---------+ | | | +---------+ |
- | | | | | | | |
- | Local | | | | | Local | |
- | Zones | | | | | Zones | |
- | |/ | | | |/
- +---------+ | | +---------+
- ]]></artwork>
- </figure>
- <t>
- Applications use the resolver to lookup GNS names.
- Starting from a configurable start zone, names are resolved by
following zone
- delegations recursively as illustrated in <xref
target="figure_arch_resolv"/>.
- 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 zone key and
to each
- other.
- 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
- without disclosing the originating zone.
- </t>
- <figure anchor="figure_arch_resolv" title="High-level view of the GNS
resolution process.">
- <artwork name="" type="" align="left" alt=""><![CDATA[
+ <t>
+ GNS exhibits the three properties that are commonly used to describe
+ a petname system:
+ </t>
+ <ol>
+ <li>
+ Global names through the concept of zone top-level
+ domains (zTLDs): As zones can be uniquely identified by their zone
key
+ and are statistically unique, zTLDs are globally unique mappings to
zones.
+ Consequently, GNS names with a zTLD suffix are also globally unique.
+ Global GNS names are not human-readable.
+ </li>
+ <li>
+ Memorable petnames for zones:
+ Users can configure local petnames for zones.
+ The petnames serve as zTLD monikers in order to support
human-readable
+ names.
+ The petnames may also be published in order to delegate namespaces
+ of zones.
+ </li>
+ <li>
+ A secure mapping from names to records:
+ GNS allows zone owners to map petnames to resource records or to
+ delegate authority of the petname to other zones and publish this
+ information.
+ The mappings are signed and encrypted using keys derived from local
+ labels.
+ When names are resolved, resource records including delegations can
+ be verified by the implementation.
+ </li>
+ </ol>
+ <t>
+ It follows from the above that GNS does not support names which are
+ simultaneously global, secure and human-readable.
+ Instead, names are either global and not human-readable or not
globally
+ unique and human-readable.
+ An example for a global name pointing to the record "example" in
+ a zone is:
+ </t>
+ <sourcecode>
+example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884
+ </sourcecode>
+ <t>
+ Now consider the petname "pet" for the example zone
+ of the name above.
+ The following name would point to the same record as the
+ globally unique name above but it is only valid locally:
+ </t>
+ <sourcecode>
+example.pet
+ </sourcecode>
+ <t>
+ The delegation of petnames and subsequent resolution of delegation
+ builds on ideas from the Simple Distributed Security Infrastructure
+ <xref target="SDSI" />.
+ In GNS, any user can create and manage one or more zones
+ (<xref target="zones"/>) as part of a zone master implementation.
+ The zone type determines the respective set of cryptographic
operations
+ and the wire formats for encrypted data, public keys and signatures.
+ A zone can be populated with mappings from labels to resource records
by
+ its owner (<xref target="rrecords"/>).
+ 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 existing DNS records.
+ </t>
+ <t>
+ Zone contents are encrypted and signed
+ before being published in a key-value storage (<xref
target="publish"/>)
+ as illustrated in <xref target="figure_arch_publish"/>.
+ In this process, unique zone identification is hidden from the network
+ through the use of key blinding.
+ 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
+ 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 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 for dedicated
infrastructure.
+ Specification of such a distributed or decentralized storage is out of
+ scope of this document, but possible existing implementations include
those
+ based on <xref target="RFC7363" />, <xref target="Kademlia" /> or
+ <xref target="R5N" />.
+ </t>
+ <figure anchor="figure_arch_publish" title="An example diagram of two
hosts publishing GNS zones.">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ Local Host | Remote | Remote Host
+ | Storage |
+ | |
+ | +---------+ |
+ | / /| |
+ Publish | +---------+ | | Publish
+ +---------+ Records | | | | | Records +---------+
+ | Zone |----------|->| Record | |<-|----------| Zone |
+ | Master | | | Storage | | | | Master |
+ +---------+ | | |/ | +---------+
+ A | +---------+ | A
+ | | | |
+ +---------+ | | +---------+
+ / | /| | | / | /|
+ +---------+ | | | +---------+ |
+ | | | | | | | |
+ | Local | | | | | Local | |
+ | Zones | | | | | Zones | |
+ | |/ | | | |/
+ +---------+ | | +---------+
+ ]]></artwork>
+ </figure>
+ <t>
+ Applications use the resolver to lookup GNS names.
+ Starting from a configurable start zone, names are resolved by
following zone
+ delegations recursively as illustrated in <xref
target="figure_arch_resolv"/>.
+ 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 zone key
and to each
+ other.
+ 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
+ without disclosing the originating zone.
+ </t>
+ <figure anchor="figure_arch_resolv" title="High-level view of the GNS
resolution process.">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
Local Host | Remote
| Storage
|
@@ -461,13 +492,13 @@
| Zones | | |
| |/ |
+---------+ |
- ]]></artwork>
- </figure>
- <t>
- In the remainder of this document, the "implementer" refers to the
developer building
- a GNS implementation including the resolver, zone master, and
- supporting configuration such as start zones (<xref
target="governance"/>).
- </t>
+ ]]></artwork>
+ </figure>
+ <t>
+ In the remainder of this document, the "implementer" refers to the
developer building
+ a GNS implementation including the resolver, zone master, and
+ supporting configuration such as start zones (<xref
target="governance"/>).
+ </t>
</section>
<section anchor="zones" numbered="true" toc="default">
<name>Zones</name>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: v19,
gnunet <=