gnunet-svn
[Top][All Lists]
Advanced

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

[lsd0001] branch master updated: attempt clarify supplemental


From: gnunet
Subject: [lsd0001] branch master updated: attempt clarify supplemental
Date: Sat, 15 Feb 2020 19:35:15 +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 4cdd050  attempt clarify supplemental
4cdd050 is described below

commit 4cdd0509dcdaa039a982c31ec81f192bea3377f4
Author: Martin Schanzenbach <address@hidden>
AuthorDate: Sat Feb 15 19:31:21 2020 +0100

    attempt clarify supplemental
---
 draft-schanzen-gns.html |  60 ++++++++++++++--
 draft-schanzen-gns.txt  | 184 +++++++++++++++++++++++++++++++-----------------
 draft-schanzen-gns.xml  |  47 +++++++++++++
 3 files changed, 223 insertions(+), 68 deletions(-)

diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 1d20fbf..11a1bb8 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -1215,6 +1215,9 @@ table {
 <li class="toc ulEmpty" id="section-toc.1-1.6.2.2.2.5">
                     <p id="section-toc.1-1.6.2.2.2.5.1"><a 
href="#section-6.2.5" class="xref">6.2.5</a>.  <a href="#name-vpn-2" 
class="xref">VPN</a><a href="#section-toc.1-1.6.2.2.2.5.1" 
class="pilcrow">¶</a></p>
 </li>
+<li class="toc ulEmpty" id="section-toc.1-1.6.2.2.2.6">
+                    <p id="section-toc.1-1.6.2.2.2.6.1"><a 
href="#section-6.2.6" class="xref">6.2.6</a>.  <a 
href="#name-supplemental-records" class="xref">Supplemental Records</a><a 
href="#section-toc.1-1.6.2.2.2.6.1" class="pilcrow">¶</a></p>
+</li>
 </ul>
 </li>
 </ul>
@@ -2317,6 +2320,55 @@ table {
              does not support setting up a tunnnel.<a href="#section-6.2.5-1" 
class="pilcrow">¶</a></p>
 </section>
 </div>
+<div id="suppl_processing">
+<section id="section-6.2.6">
+          <h4 id="name-supplemental-records">
+<a href="#section-6.2.6" class="section-number selfRef">6.2.6. </a><a 
href="#name-supplemental-records" class="section-name selfRef">Supplemental 
Records</a>
+          </h4>
+<p id="section-6.2.6-1">
+             Supplemental records are only relevant to the recursive resolver
+             if the record set in question is the final result which is to
+             be returned to the client. The resolver only returns a record set
+             including the supplemental records if one of the non-supplemental
+             records matches the queried record type.
+             Supplemental records MUST NOT be published and resolved under the
+             empty label. If a resolver encounters a supplemental under the
+             empty label, it MUST discard the record.<a 
href="#section-6.2.6-1" class="pilcrow">¶</a></p>
+<p id="section-6.2.6-2">
+             The differentiation between a supplemental and non-supplemental
+             record allows the client to match the record to the authoritative
+             zone. Consider the following example:<a href="#section-6.2.6-2" 
class="pilcrow">¶</a></p>
+<figure id="figure-14">
+            <div class="artwork art-text alignLeft" id="section-6.2.6-3.1">
+<pre>
+           Query: alice.bob (type=A)
+           Result:
+           A: 1.2.3.4
+           NICK: Alice
+         </pre>
+</div>
+<figcaption><a href="#figure-14" class="selfRef">Figure 
14</a></figcaption></figure>
+<p id="section-6.2.6-4">
+          In this example, the returned NICK record is non-supplemental.
+          For the client, this means that the NICK belongs to the zone
+          "alice.bob" and is published under the empty label along with an A
+          record. In contrast, if the resolution yields the following:<a 
href="#section-6.2.6-4" class="pilcrow">¶</a></p>
+<figure id="figure-15">
+            <div class="artwork art-text alignLeft" id="section-6.2.6-5.1">
+<pre>
+           Query: alice.bob (type=A)
+           Result:
+           A: 1.2.3.4
+           NICK: Bob (Supplemental)
+         </pre>
+</div>
+<figcaption><a href="#figure-15" class="selfRef">Figure 
15</a></figcaption></figure>
+<p id="section-6.2.6-6">
+       In this case, the NICK record is marked as supplemental. This means that
+       the NICK record belongs to the zone "bob" and is published under the
+       label "alice" along with an A record.<a href="#section-6.2.6-6" 
class="pilcrow">¶</a></p>
+</section>
+</div>
 </section>
 </div>
 </section>
@@ -2343,7 +2395,7 @@ table {
          The following the the basic data "REVDAT" on which the proof-of work 
is
          calculated:<a href="#section-7-3" class="pilcrow">¶</a></p>
 <div id="figure_revocation">
-<figure id="figure-14">
+<figure id="figure-16">
         <div class="artwork art-text alignLeft" id="section-7-4.1">
 <pre>
            0     8     16    24    32    40    48    56
@@ -2357,11 +2409,11 @@ table {
            +-----+-----+-----+-----+-----+-----+-----+-----+
            </pre>
 </div>
-<figcaption><a href="#figure-14" class="selfRef">Figure 
14</a></figcaption></figure>
+<figcaption><a href="#figure-16" class="selfRef">Figure 
16</a></figcaption></figure>
 </div>
 <p id="section-7-5">
          A single pass in the proof-of-work algorithm is defined as follows:<a 
href="#section-7-5" class="pilcrow">¶</a></p>
-<figure id="figure-15">
+<figure id="figure-17">
         <div class="artwork art-text alignLeft" id="section-7-6.1">
 <pre>
          DK := scrypt (P := REV)
@@ -2370,7 +2422,7 @@ table {
          REVDATA := scrypt(P := enc)
          </pre>
 </div>
-<figcaption><a href="#figure-15" class="selfRef">Figure 
15</a></figcaption></figure>
+<figcaption><a href="#figure-17" class="selfRef">Figure 
17</a></figcaption></figure>
 <p id="section-7-7">
        where "scrypt" is the scrypt algorithm as defined in
        <span>[<a href="#RFC7914" class="xref">RFC7914</a>]</span> with the 
following parameters set:<a href="#section-7-7" class="pilcrow">¶</a></p>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index 221dbc6..d6aa536 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -83,12 +83,13 @@ Table of Contents
        6.2.3.  CNAME . . . . . . . . . . . . . . . . . . . . . . . .  18
        6.2.4.  BOX . . . . . . . . . . . . . . . . . . . . . . . . .  18
        6.2.5.  VPN . . . . . . . . . . . . . . . . . . . . . . . . .  18
+       6.2.6.  Supplemental Records  . . . . . . . . . . . . . . . .  19
    7.  Zone Revocation . . . . . . . . . . . . . . . . . . . . . . .  19
    8.  Determining the Root Zone and Zone Governance . . . . . . . .  20
-   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
-   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
-   11. Test Vectors  . . . . . . . . . . . . . . . . . . . . . . . .  21
-   12. Normative References  . . . . . . . . . . . . . . . . . . . .  23
+   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
+   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
+   11. Test Vectors  . . . . . . . . . . . . . . . . . . . . . . . .  22
+   12. Normative References  . . . . . . . . . . . . . . . . . . . .  24
    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25
 
 1.  Introduction
@@ -105,7 +106,6 @@ Table of Contents
    DNS was not designed with security as a goal.  This makes it very
    vulnerable, especially to attackers that have the technical
    capabilities of an entire nation state at their disposal.  This
-   specification describes a censorship-resistant, privacy-preserving
 
 
 
@@ -114,6 +114,7 @@ Schanzenbach, et al.       Expires 13 May 2020              
    [Page 2]
 Internet-Draft             The GNU Name System             November 2019
 
 
+   specification describes a censorship-resistant, privacy-preserving
    and decentralized name system: The GNU Name System (GNS).  It is
    designed to provide a secure alternative to DNS, especially when
    censorship or manipulation is encountered.  GNS can bind names to any
@@ -164,7 +165,6 @@ Internet-Draft             The GNU Name System             
November 2019
 
 
 
-
 Schanzenbach, et al.       Expires 13 May 2020                  [Page 3]
 
 Internet-Draft             The GNU Name System             November 2019
@@ -1010,6 +1010,44 @@ Schanzenbach, et al.       Expires 13 May 2020           
      [Page 18]
 Internet-Draft             The GNU Name System             November 2019
 
 
+6.2.6.  Supplemental Records
+
+   Supplemental records are only relevant to the recursive resolver if
+   the record set in question is the final result which is to be
+   returned to the client.  The resolver only returns a record set
+   including the supplemental records if one of the non-supplemental
+   records matches the queried record type.  Supplemental records MUST
+   NOT be published and resolved under the empty label.  If a resolver
+   encounters a supplemental under the empty label, it MUST discard the
+   record.
+
+   The differentiation between a supplemental and non-supplemental
+   record allows the client to match the record to the authoritative
+   zone.  Consider the following example:
+
+              Query: alice.bob (type=A)
+              Result:
+              A: 1.2.3.4
+              NICK: Alice
+
+                                 Figure 14
+
+   In this example, the returned NICK record is non-supplemental.  For
+   the client, this means that the NICK belongs to the zone "alice.bob"
+   and is published under the empty label along with an A record.  In
+   contrast, if the resolution yields the following:
+
+              Query: alice.bob (type=A)
+              Result:
+              A: 1.2.3.4
+              NICK: Bob (Supplemental)
+
+                                 Figure 15
+
+   In this case, the NICK record is marked as supplemental.  This means
+   that the NICK record belongs to the zone "bob" and is published under
+   the label "alice" along with an A record.
+
 7.  Zone Revocation
 
    Whenever a recursive resolver encounters a new GNS zone, it MUST
@@ -1020,6 +1058,14 @@ Internet-Draft             The GNU Name System           
  November 2019
    In order to revoke a zone key, a signed revocation object SHOULD be
    published.  This object MUST be signed using the private zone key.
    The revocation object is flooded in the overlay network.  To prevent
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 19]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
    flooding attacks, the revocation message MUST contain a proof-of-
    work.  The revocation message including the proof-of-work MAY be
    calculated ahead of time to support timely revocation.
@@ -1037,7 +1083,7 @@ Internet-Draft             The GNU Name System            
 November 2019
               |                                               |
               +-----+-----+-----+-----+-----+-----+-----+-----+
 
-                                 Figure 14
+                                 Figure 16
 
    A single pass in the proof-of-work algorithm is defined as follows:
 
@@ -1046,7 +1092,7 @@ Internet-Draft             The GNU Name System            
 November 2019
             EREV := AES (DK, IV, REV) /* TODO this is more complex */
             REVDATA := scrypt(P := enc)
 
-                                 Figure 15
+                                 Figure 17
 
    where "scrypt" is the scrypt algorithm as defined in [RFC7914] with
    the following parameters set:
@@ -1057,15 +1103,6 @@ Internet-Draft             The GNU Name System           
  November 2019
             p := 2 /* Parallelization parameter */
             dkLen := 512 /* Intended output length */
 
-
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 19]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
    The above function is called with different values for the "NONCE" in
    "REVDAT" until the amount of leading zeroes is greater or equal 25.
 
@@ -1077,6 +1114,14 @@ Internet-Draft             The GNU Name System           
  November 2019
    points to a local or remote start zone key.  A resolver client may
    also determine the start zone from the suffix of the name given for
    resolution or using information retrieved out of band.  The
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 20]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
    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
    discretion of the local system administrator or user.
@@ -1108,20 +1153,6 @@ Internet-Draft             The GNU Name System           
  November 2019
    locally managed zone matches the suffix of the name to be resolved,
    resolution SHOULD start from the respective local zone:
 
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 20]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
             Example name: www.example.gnu
             Local zones:
             fr = (d0,zk0)
@@ -1138,6 +1169,15 @@ Internet-Draft             The GNU Name System           
  November 2019
    ".".  If multiple suffixes match the name to resolve, the longest
    matching suffix MUST BE used.  The suffix length of two results
    cannot be equal, as this would indicate a misconfiguration.  If both
+
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 21]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
    a locally managed zone and a configuration entry exist for the same
    suffix, the locally managed zone MUST have priority.
 
@@ -1171,13 +1211,6 @@ Internet-Draft             The GNU Name System           
  November 2019
             f89333903b284fe8
             1878bf47f3b39da0
 
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 21]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
             zk (public zone key) :=
             dff911496d025d7e
             0885c03d19153e99
@@ -1194,6 +1227,13 @@ Internet-Draft             The GNU Name System           
  November 2019
             6668e9f684f4dc33
             6d656b27392b0fee
 
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 22]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
             d_h :=
             01fb61f482c17633
             77611c4c2509e0f3
@@ -1226,14 +1266,6 @@ Internet-Draft             The GNU Name System           
  November 2019
             3425e8a811ae59d2
             99e2747285d2a479
 
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 22]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
             TWOFISH_IV :=
             071be189a9d236f9
             b4a3654bb8c281d4
@@ -1250,6 +1282,14 @@ Internet-Draft             The GNU Name System           
  November 2019
             00000000
 
 
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 23]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
             RRBLOCK :=
             055cb070e05fe6de SIGNATURE
             ad694a50e5b4dedd
@@ -1281,15 +1321,6 @@ Internet-Draft             The GNU Name System           
  November 2019
               STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
               <https://www.rfc-editor.org/info/rfc1034>.
 
-
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 23]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
    [RFC1035]  Mockapetris, P., "Domain names - implementation and
               specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
               November 1987, <https://www.rfc-editor.org/info/rfc1035>.
@@ -1308,6 +1339,13 @@ Internet-Draft             The GNU Name System           
  November 2019
               10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
               2003, <https://www.rfc-editor.org/info/rfc3629>.
 
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 24]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
    [RFC3826]  Blumenthal, U., Maino, F., and K. McCloghrie, "The
               Advanced Encryption Standard (AES) Cipher Algorithm in the
               SNMP User-based Security Model", RFC 3826,
@@ -1338,14 +1376,6 @@ Internet-Draft             The GNU Name System           
  November 2019
               Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
               2013, <https://www.rfc-editor.org/info/rfc6979>.
 
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 24]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
    [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
               for Security", RFC 7748, DOI 10.17487/RFC7748, January
               2016, <https://www.rfc-editor.org/info/rfc7748>.
@@ -1364,6 +1394,14 @@ Internet-Draft             The GNU Name System           
  November 2019
 
 Authors' Addresses
 
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 25]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
    Martin Schanzenbach
    GNUnet e.V.
    Boltzmannstrasse 3
@@ -1397,4 +1435,22 @@ Authors' Addresses
 
 
 
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 25]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 26]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 9d5a23c..da0ead1 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1071,6 +1071,53 @@
              does not support setting up a tunnnel.
            </t>
          </section>
+         <section anchor="suppl_processing" numbered="true" toc="default">
+           <name>Supplemental Records</name>
+           <t>
+             Supplemental records are only relevant to the recursive resolver
+             if the record set in question is the final result which is to
+             be returned to the client. The resolver only returns a record set
+             including the supplemental records if one of the non-supplemental
+             records matches the queried record type.
+             Supplemental records MUST NOT be published and resolved under the
+             empty label. If a resolver encounters a supplemental under the
+             empty label, it MUST discard the record.
+           </t>
+           <t>
+             The differentiation between a supplemental and non-supplemental
+             record allows the client to match the record to the authoritative
+             zone. Consider the following example:
+           </t>
+       <figure>
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+           Query: alice.bob (type=A)
+           Result:
+           A: 1.2.3.4
+           NICK: Alice
+         ]]></artwork>
+        </figure>
+        <t>
+          In this example, the returned NICK record is non-supplemental.
+          For the client, this means that the NICK belongs to the zone
+          "alice.bob" and is published under the empty label along with an A
+          record. In contrast, if the resolution yields the following:
+        </t>
+       <figure>
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+           Query: alice.bob (type=A)
+           Result:
+           A: 1.2.3.4
+           NICK: Bob (Supplemental)
+         ]]></artwork>
+     </figure>
+     <t>
+       In this case, the NICK record is marked as supplemental. This means that
+       the NICK record belongs to the zone "bob" and is published under the
+       label "alice" along with an A record.
+      </t>
+
+
+         </section>
        </section>
      </section>
      <section anchor="revocation" numbered="true" toc="default">

-- 
To stop receiving notification emails like this one, please contact
address@hidden.



reply via email to

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