gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lsd0001] branch master updated: add rfc8324; multiple storages


From: gnunet
Subject: [lsd0001] branch master updated: add rfc8324; multiple storages
Date: Mon, 17 Jan 2022 20:13:04 +0100

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 c141ae5  add rfc8324; multiple storages
c141ae5 is described below

commit c141ae5eb24dadd18e2c05ad0ee877642d258570
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Mon Jan 17 20:13:00 2022 +0100

    add rfc8324; multiple storages
---
 draft-schanzen-gns.xml | 39 +++++++++++++++++++++++++++++++++++----
 1 file changed, 35 insertions(+), 4 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index f62002c..cf3becc 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -20,6 +20,7 @@
 <!ENTITY RFC8032 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml";>
 <!ENTITY RFC8126 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml";>
 <!ENTITY RFC8174 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml";>
+<!ENTITY RFC8324 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8324.xml";>
 <!ENTITY RFC8499 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8499.xml";>
 <!ENTITY RFC9106 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.9106.xml";>
 ]>
@@ -103,7 +104,7 @@
      <t>
        The Domain Name System (DNS) <xref target="RFC1035" /> is a unique
        distributed database and a vital service for most Internet applications.
-       While DNS is distributed, it
+       While DNS is distributed, in practice it
        relies on centralized, trusted registrars to provide globally unique
        names. As the awareness of the central role DNS plays on the Internet
        rises, various institutions are using their power (including legal 
means)
@@ -118,6 +119,10 @@
        and decentralized name system: The GNU Name System (GNS) <xref 
target="GNS" />.
        It is designed to provide a secure, privacy-enhancing alternative to
        DNS, especially when censorship or manipulation is encountered.
+       In particular, it directly addresses concerns in DNS with respect to 
"Query
+       Privacy", the "Single Hierarchy with a Centrally Controlled Root" and
+       "Distribution and Management of Root Servers" as raised in
+       <xref target="RFC8324"/>.
        GNS can bind names to any kind of
        cryptographically secured token, enabling it to double in some respects 
as
        even as an alternative to some of today’s Public Key Infrastructures, in
@@ -787,7 +792,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
      <name>Zone Delegation Records</name>
      <t>
        This section defines the initial set of zone delegation record types.
-       Any implementation MUST support at least one of the zone types and
+       Any implementation MUST support all zone types defined here and
        MAY support any number of additional delegation records defined in
        the GNU Name System Record Types registry <xref target="gana"/>.
        Zone delegation records MUST NOT be stored and published under the
@@ -1436,7 +1441,11 @@ GET(key) -> value
        encrypted and published together in a single resource records block
        (RRBLOCK) in the storage under a key q: PUT(q, RRBLOCK).
        The key q is derived from the zone key and the respective
-       label of the contained records. The storage key derivation and records
+       label of the contained records.
+       The required knowledge of both zone key and label in combination
+       with the similarly derived symmetric secret keys and blinded zone keys
+       ensure query privacy (see <xref target="RFC8324"/>, Section 3.5).
+       The storage key derivation and records
        block creation is specified in the following sections.
        A client implementation MUST enable the user the manage zones.
        The implementation MUST use the PUT storage procedure in order to update
@@ -1666,8 +1675,12 @@ q := SHA512 (HDKD-Public(zk, label))
          suffix of the name given for resolution or using information
    retrieved out of band.
          The governance model of any zone is at the sole discretion
-         of the zone owner. However, the choice of start zone(s) is at the sole
+         of the zone owner.
+         However, the choice of start zone(s) is at the sole
          discretion of the local system administrator or user.
+         This property addresses the issue of a single hierarchy with a
+         centrally controlled root and the related issue of distribution and
+         management of root servers in DNS (see <xref target="RFC8324"/>, 
Section 3.10 and 3.12).
        </t>
         <t>
          In the following, we give examples how a local client resolver SHOULD
@@ -2104,6 +2117,23 @@ NICK: john (Supplemental)
            Extension and customization of the zone is at the full discretion of
            the user.
          </t>
+         <t>
+           While implementations following this specification will be
+           interoperable, if two implementations connect to different storages
+           they are mutually unreachable.
+           This may lead to a state where a record may exist in the global
+           namespace for a particular name, but the implementation is not
+           communicating with the storage and is hence unable to resolve it.
+           This situation is similar to a split-horizon DNS configuration.
+           Which storages are implemented usually depend on the application
+           it is built for.
+           The storage used will most likely depend on the specific application
+           context using GNS resolution.
+           For example, one application may be the resolution of hidden 
services
+           within the Tor network.
+           Implementations of "aggregated" storages are conceivable, but
+           are expected to be the exception.
+         </t>
        </section>
        <section anchor="security_dht" numbered="true" toc="default">
          <name>Impact of DHTs as Underlying Storage</name>
@@ -2704,6 +2734,7 @@ cae1789d
        <name>Informative References</name>
          &RFC6781;
          &RFC7363;
+         &RFC8324;
        <!--         &RFC3912;-->
 
        <reference anchor="Tor224" 
target="https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n2135";>

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]