gnunet-svn
[Top][All Lists]
Advanced

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

[lsd0001] branch master updated: more revocation


From: gnunet
Subject: [lsd0001] branch master updated: more revocation
Date: Mon, 10 Feb 2020 21:34:02 +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 1e4f990  more revocation
1e4f990 is described below

commit 1e4f9902a4c03d8b5f40d189f590c5ad0155ffd9
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Mon Feb 10 21:30:12 2020 +0100

    more revocation
---
 draft-schanzen-gns.html | 101 +++++++++++++++++++--------------
 draft-schanzen-gns.txt  | 148 ++++++++++++++++++++++++------------------------
 draft-schanzen-gns.xml  | 137 ++++++++++++++++++++++++++------------------
 3 files changed, 215 insertions(+), 171 deletions(-)

diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 57bec4a..200b84e 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -2082,32 +2082,32 @@ async function addMetadata(){try{const 
e=document.styleSheets[0].cssRules;for(le
            is the result and the recursion is concluded.<a 
href="#section-6.2-2.1" class="pilcrow">¶</a>
 </li>
           <li id="section-6.2-2.2">
-    Case 2:
-    If the name to be resolved is of the format
-    "_SERVICE._PROTO" and the record set contains one or more matching BOX
-    records, the records in the BOX records are the result and the recusion
-    is concluded (<a href="#box_processing" class="xref">Section 6.2.4</a>).<a 
href="#section-6.2-2.2" class="pilcrow">¶</a>
+     Case 2:
+     If the name to be resolved is of the format
+     "_SERVICE._PROTO" and the record set contains one or more matching BOX
+     records, the records in the BOX records are the result and the recusion
+     is concluded (<a href="#box_processing" class="xref">Section 
6.2.4</a>).<a href="#section-6.2-2.2" class="pilcrow">¶</a>
 </li>
           <li id="section-6.2-2.3">
            Case 3:
            If the remainder of the name to resolve is not empty and
-    does not match the "_SERVICE._PROTO" syntax, then the current record set
+     does not match the "_SERVICE._PROTO" syntax, then the current record set
            MUST consist of a single PKEY record
-    (<a href="#pkey_processing" class="xref">Section 6.2.1</a>),
-    a single CNAME record
-    (<a href="#cname_processing" class="xref">Section 6.2.3</a>),
+     (<a href="#pkey_processing" class="xref">Section 6.2.1</a>),
+     a single CNAME record
+     (<a href="#cname_processing" class="xref">Section 6.2.3</a>),
            or one or more GNS2DNS records
-    (<a href="#gns2dns_processing" class="xref">Section 6.2.2</a>),
-    which are processed
-    as described in the respective sections below.
-    Otherwise, resolution fails
+     (<a href="#gns2dns_processing" class="xref">Section 6.2.2</a>),
+     which are processed
+     as described in the respective sections below.
+     Otherwise, resolution fails
            and the resolver MUST return an empty record set.
 
-    Finally, after the recursion terminates, the client preferences
-    for the record type SHOULD be considered. If a VPN record is found
-    and the client requests an A or AAAA record, the VPN record
-    SHOULD be converted (<a href="#vpn_processing" class="xref">Section 
6.2.5</a>)
-    if possible.<a href="#section-6.2-2.3" class="pilcrow">¶</a>
+     Finally, after the recursion terminates, the client preferences
+     for the record type SHOULD be considered. If a VPN record is found
+     and the client requests an A or AAAA record, the VPN record
+     SHOULD be converted (<a href="#vpn_processing" class="xref">Section 
6.2.5</a>)
+     if possible.<a href="#section-6.2-2.3" class="pilcrow">¶</a>
 </li>
         </ol>
 <div id="pkey_processing">
@@ -2170,15 +2170,15 @@ async function addMetadata(){try{const 
e=document.styleSheets[0].cssRules;for(le
              record (<a href="#gnsrecords_leho" class="xref">Section 3.4</a>) 
with a relative
              expiration time of one hour.<a href="#section-6.2.2-4" 
class="pilcrow">¶</a></p>
 <p id="section-6.2.2-5">
-      GNS resolvers SHOULD offer a configuration
-      option to disable DNS processing to avoid information leakage
-      and provide a consistent security profile for all name resolutions.
-      Such resolvers would return an empty record set upon encountering
-      a GNS2DNS record during the recursion. However, if GNS2DNS records
-      are encountered in the record set for the apex and a GNS2DNS record
-      is expicitly requested by the application, such records MUST
-      still be returned, even if DNS support is disabled by the
-      GNS resolver configuration.<a href="#section-6.2.2-5" 
class="pilcrow">¶</a></p>
+       GNS resolvers SHOULD offer a configuration
+       option to disable DNS processing to avoid information leakage
+       and provide a consistent security profile for all name resolutions.
+       Such resolvers would return an empty record set upon encountering
+       a GNS2DNS record during the recursion. However, if GNS2DNS records
+       are encountered in the record set for the apex and a GNS2DNS record
+       is expicitly requested by the application, such records MUST
+       still be returned, even if DNS support is disabled by the
+       GNS resolver configuration.<a href="#section-6.2.2-5" 
class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="cname_processing">
@@ -2226,7 +2226,7 @@ async function addMetadata(){try{const 
e=document.styleSheets[0].cssRules;for(le
 <a href="#section-6.2.5" class="section-number selfRef">6.2.5. </a><a 
href="#name-vpn-2" class="section-name selfRef">VPN</a>
           </h4>
 <p id="section-6.2.5-1">
-      At the end of the recursion,
+       At the end of the recursion,
              if the queried record type is either A or AAAA and the retrieved
              record set contains at least one VPN record, the resolver SHOULD
              open a tunnel and return the IPv4 or IPv6 tunnel address,
@@ -2283,16 +2283,28 @@ async function addMetadata(){try{const 
e=document.styleSheets[0].cssRules;for(le
 <figure id="figure-15">
         <div class="artwork art-text alignLeft" id="section-7-6.1">
 <pre>
-         skey := kdf_scrypt (salt="gnunet-revocation-proof-of-work", REVDAT)
-         skey_iv := iv_derive (salt="gnunet-revocation-proof-of-work", 
"gnunet-proof-of-work-iv", skey)
-         enc := AES (skey, skey_iv, REVDAT)
-         REV := kdf_scrypt(salt="gnunet-revocation-proof-of-work", enc)
+         DK := scrypt (P := REV)
+         IV := IVderive (salt="gnunet-revocation-proof-of-work", 
"gnunet-proof-of-work-iv", DK)
+         EREV := AES (DK, IV, REV) /* TODO this is more complex */
+         REVDATA := scrypt(P := enc)
          </pre>
 </div>
 <figcaption><a href="#figure-15" class="selfRef">Figure 
15</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>
+<div class="artwork art-text alignLeft" id="section-7-8">
+<pre>
+         S := "gnunet-revocation-proof-of-work" /* Salt */
+         N := 1 /* CPU memory cost parameter TODO spec says &gt;1!!! */
+         r := 8 /* Block size */
+         p := 2 /* Parallelization parameter */
+         dkLen := 512 /* Intended output length */
+         </pre><a href="#section-7-8" class="pilcrow">¶</a>
+</div>
+<p id="section-7-9">
        The above function is called with different values for the "NONCE" in
-       "REVDAT" until the amount of leading zeroes is greater or equal 25.<a 
href="#section-7-7" class="pilcrow">¶</a></p>
+       "REVDAT" until the amount of leading zeroes is greater or equal 25.<a 
href="#section-7-9" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="governance">
@@ -2307,7 +2319,7 @@ async function addMetadata(){try{const 
e=document.styleSheets[0].cssRules;for(le
          which 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.
+   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
          discretion of the local system administrator or user.<a 
href="#section-8-1" class="pilcrow">¶</a></p>
@@ -2316,13 +2328,13 @@ async function addMetadata(){try{const 
e=document.styleSheets[0].cssRules;for(le
          where root zone governance is centralized at the Internet Corporation
          for Assigned Names and Numbers (ICANN).
          In DNS terminology, GNS roughly follows the idea of a hyper-hyper
-  local root zone deployment, with the difference that it is not
-  expected that all deployments use the same local root zone.<a 
href="#section-8-2" class="pilcrow">¶</a></p>
+   local root zone deployment, with the difference that it is not
+   expected that all deployments use the same local root zone.<a 
href="#section-8-2" class="pilcrow">¶</a></p>
 <p id="section-8-3">
          In the following, we give examples how a local client resolver SHOULD
          discover the start zone.  The process given is not exhaustive and
          clients MAY suppliement it with other mechanisms or ignore it if the
-  particular application requires a different process.<a href="#section-8-3" 
class="pilcrow">¶</a></p>
+   particular application requires a different process.<a href="#section-8-3" 
class="pilcrow">¶</a></p>
 <p id="section-8-4">
          GNS clients SHOULD first try to interpret the top-level domain of
          a GNS name as a zone key.
@@ -2339,11 +2351,11 @@ async function addMetadata(){try{const 
e=document.styleSheets[0].cssRules;for(le
 <p id="section-8-6">
          In GNS, users MAY own and manage their own zones.
          Each local zone SHOULD be associated with a single GNS label,
-  but users MAY choose to use longer names consisting of
-  multiple labels.
+   but users MAY choose to use longer names consisting of
+   multiple labels.
          If the name of a locally managed zone matches the suffix
-  of the name to be resolved,
-  resolution SHOULD start from the respective local zone:<a 
href="#section-8-6" class="pilcrow">¶</a></p>
+   of the name to be resolved,
+   resolution SHOULD start from the respective local zone:<a 
href="#section-8-6" class="pilcrow">¶</a></p>
 <div class="artwork art-text alignLeft" id="section-8-7">
 <pre>
          Example name: www.example.gnu
@@ -2364,8 +2376,8 @@ async function addMetadata(){try{const 
e=document.styleSheets[0].cssRules;for(le
          ".". 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 a locally managed zone and a configuration entry exist
-  for the same suffix, the locally managed zone MUST have priority.<a 
href="#section-8-8" class="pilcrow">¶</a></p>
+   If both a locally managed zone and a configuration entry exist
+   for the same suffix, the locally managed zone MUST have priority.<a 
href="#section-8-8" class="pilcrow">¶</a></p>
 <div class="artwork art-text alignLeft" id="section-8-9">
 <pre>
          Example name: www.example.gnu
@@ -2547,6 +2559,9 @@ async function addMetadata(){try{const 
e=document.styleSheets[0].cssRules;for(le
 <dt id="RFC7748">[RFC7748]</dt>
       <dd>
 <span class="refAuthor">Langley, A.</span><span class="refAuthor">, Hamburg, 
M.</span><span class="refAuthor">, and S. Turner</span>, <span 
class="refTitle">"Elliptic Curves for Security"</span>, <span 
class="seriesInfo">RFC 7748</span>, <span class="seriesInfo">DOI 
10.17487/RFC7748</span>, <time datetime="2016-01">January 2016</time>, 
<span>&lt;<a 
href="https://www.rfc-editor.org/info/rfc7748";>https://www.rfc-editor.org/info/rfc7748</a>&gt;</span>.
 </dd>
+<dt id="RFC7914">[RFC7914]</dt>
+      <dd>
+<span class="refAuthor">Percival, C.</span><span class="refAuthor"> and S. 
Josefsson</span>, <span class="refTitle">"The scrypt Password-Based Key 
Derivation Function"</span>, <span class="seriesInfo">RFC 7914</span>, <span 
class="seriesInfo">DOI 10.17487/RFC7914</span>, <time datetime="2016-08">August 
2016</time>, <span>&lt;<a 
href="https://www.rfc-editor.org/info/rfc7914";>https://www.rfc-editor.org/info/rfc7914</a>&gt;</span>.
 </dd>
 <dt id="RFC8032">[RFC8032]</dt>
       <dd>
 <span class="refAuthor">Josefsson, S.</span><span class="refAuthor"> and I. 
Liusvaara</span>, <span class="refTitle">"Edwards-Curve Digital Signature 
Algorithm (EdDSA)"</span>, <span class="seriesInfo">RFC 8032</span>, <span 
class="seriesInfo">DOI 10.17487/RFC8032</span>, <time 
datetime="2017-01">January 2017</time>, <span>&lt;<a 
href="https://www.rfc-editor.org/info/rfc8032";>https://www.rfc-editor.org/info/rfc8032</a>&gt;</span>.
 </dd>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index ee95795..1647f06 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -84,12 +84,12 @@ Table of Contents
        6.2.4.  BOX . . . . . . . . . . . . . . . . . . . . . . . . .  18
        6.2.5.  VPN . . . . . . . . . . . . . . . . . . . . . . . . .  18
    7.  Zone Revocation . . . . . . . . . . . . . . . . . . . . . . .  19
-   8.  Determining the Root Zone and Zone Governance . . . . . . . .  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
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25
 
 1.  Introduction
 
@@ -1041,23 +1041,23 @@ Internet-Draft             The GNU Name System          
   November 2019
 
    A single pass in the proof-of-work algorithm is defined as follows:
 
-            skey := kdf_scrypt (salt="gnunet-revocation-proof-of-work", REVDAT)
-            skey_iv := iv_derive (salt="gnunet-revocation-proof-of-work", 
"gnunet-proof-of-work-iv", skey)
-            enc := AES (skey, skey_iv, REVDAT)
-            REV := kdf_scrypt(salt="gnunet-revocation-proof-of-work", enc)
+            DK := scrypt (P := REV)
+            IV := IVderive (salt="gnunet-revocation-proof-of-work", 
"gnunet-proof-of-work-iv", DK)
+            EREV := AES (DK, IV, REV) /* TODO this is more complex */
+            REVDATA := scrypt(P := enc)
 
                                  Figure 15
 
-   The above function is called with different values for the "NONCE" in
-   "REVDAT" until the amount of leading zeroes is greater or equal 25.
+   where "scrypt" is the scrypt algorithm as defined in [RFC7914] with
+   the following parameters set:
+
+            S := "gnunet-revocation-proof-of-work" /* Salt */
+            N := 1 /* CPU memory cost parameter TODO spec says >1!!! */
+            r := 8 /* Block size */
+            p := 2 /* Parallelization parameter */
+            dkLen := 512 /* Intended output length */
 
-8.  Determining the Root Zone and Zone Governance
 
-   The resolution of a GNS name must start in a given start zone
-   indicated to the resolver using any public zone key.  The local
-   resolver may have a local start zone configured/hard-coded which
-   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
 
 
 
@@ -1066,6 +1066,16 @@ 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.
+
+8.  Determining the Root Zone and Zone Governance
+
+   The resolution of a GNS name must start in a given start zone
+   indicated to the resolver using any public zone key.  The local
+   resolver may have a local start zone configured/hard-coded which
+   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
    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
@@ -1098,6 +1108,20 @@ 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)
@@ -1114,14 +1138,6 @@ 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 20]
-
-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.
 
@@ -1155,6 +1171,13 @@ 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
@@ -1171,13 +1194,6 @@ Internet-Draft             The GNU Name System           
  November 2019
             6668e9f684f4dc33
             6d656b27392b0fee
 
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 21]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
             d_h :=
             01fb61f482c17633
             77611c4c2509e0f3
@@ -1210,6 +1226,14 @@ 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
@@ -1226,14 +1250,6 @@ Internet-Draft             The GNU Name System           
  November 2019
             00000000
 
 
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 22]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
             RRBLOCK :=
             055cb070e05fe6de SIGNATURE
             ad694a50e5b4dedd
@@ -1265,6 +1281,15 @@ 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>.
@@ -1283,13 +1308,6 @@ 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 23]
-
-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,
@@ -1320,10 +1338,22 @@ 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>.
 
+   [RFC7914]  Percival, C. and S. Josefsson, "The scrypt Password-Based
+              Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914,
+              August 2016, <https://www.rfc-editor.org/info/rfc7914>.
+
    [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
               Signature Algorithm (EdDSA)", RFC 8032,
               DOI 10.17487/RFC8032, January 2017,
@@ -1338,14 +1368,6 @@ Authors' Addresses
    GNUnet e.V.
    Boltzmannstrasse 3
    85748 Garching
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 24]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
    Germany
 
    Email: address@hidden
@@ -1375,26 +1397,4 @@ Internet-Draft             The GNU Name System           
  November 2019
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
 Schanzenbach, et al.       Expires 13 May 2020                 [Page 25]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 9d98a63..3a27817 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -899,48 +899,48 @@
        </section>
        <section anchor="record_processing" numbered="true" toc="default">
          <name>Record Processing</name>
-        <t>
+   <t>
            Record processing occurs at the end of a single recursion. We assume
            that the RRBLOCK has been cryptographically verified and decrypted.
            At this point, we must first determine if we have received a valid
            record set in the context of the name we are trying to resolve:
          </t>
-        <ol>
+   <ol>
          <li>
            Case 1:
            If the remainder of the name to resolve is empty and the record set
            does not consist of a PKEY, CNAME or DNS2GNS record, the record set
            is the result and the recursion is concluded.
          </li>
-        <li>
-          Case 2:
-          If the name to be resolved is of the format
-          "_SERVICE._PROTO" and the record set contains one or more matching 
BOX
-          records, the records in the BOX records are the result and the 
recusion
-          is concluded (<xref target="box_processing" />).
-        </li>
+   <li>
+     Case 2:
+     If the name to be resolved is of the format
+     "_SERVICE._PROTO" and the record set contains one or more matching BOX
+     records, the records in the BOX records are the result and the recusion
+     is concluded (<xref target="box_processing" />).
+   </li>
          <li>
            Case 3:
            If the remainder of the name to resolve is not empty and
-          does not match the "_SERVICE._PROTO" syntax, then the current record 
set
+     does not match the "_SERVICE._PROTO" syntax, then the current record set
            MUST consist of a single PKEY record
-          (<xref target="pkey_processing" />),
-          a single CNAME record
-          (<xref target="cname_processing" />),
+     (<xref target="pkey_processing" />),
+     a single CNAME record
+     (<xref target="cname_processing" />),
            or one or more GNS2DNS records
-          (<xref target="gns2dns_processing" />),
-          which are processed
-          as described in the respective sections below.
-          Otherwise, resolution fails
+     (<xref target="gns2dns_processing" />),
+     which are processed
+     as described in the respective sections below.
+     Otherwise, resolution fails
            and the resolver MUST return an empty record set.
 
-          Finally, after the recursion terminates, the client preferences
-          for the record type SHOULD be considered. If a VPN record is found
-          and the client requests an A or AAAA record, the VPN record
-          SHOULD be converted (<xref target="vpn_processing" />)
-          if possible.
-        </li>
-        </ol>
+     Finally, after the recursion terminates, the client preferences
+     for the record type SHOULD be considered. If a VPN record is found
+     and the client requests an A or AAAA record, the VPN record
+     SHOULD be converted (<xref target="vpn_processing" />)
+     if possible.
+   </li>
+   </ol>
          <section anchor="pkey_processing" numbered="true" toc="default">
            <name>PKEY</name>
            <t>
@@ -999,17 +999,17 @@
              record (<xref target="gnsrecords_leho" />) with a relative
              expiration time of one hour.
            </t>
-          <t>
-            GNS resolvers SHOULD offer a configuration
-            option to disable DNS processing to avoid information leakage
-            and provide a consistent security profile for all name resolutions.
-            Such resolvers would return an empty record set upon encountering
-            a GNS2DNS record during the recursion. However, if GNS2DNS records
-            are encountered in the record set for the apex and a GNS2DNS record
-            is expicitly requested by the application, such records MUST
-            still be returned, even if DNS support is disabled by the
-            GNS resolver configuration.
-          </t>
+     <t>
+       GNS resolvers SHOULD offer a configuration
+       option to disable DNS processing to avoid information leakage
+       and provide a consistent security profile for all name resolutions.
+       Such resolvers would return an empty record set upon encountering
+       a GNS2DNS record during the recursion. However, if GNS2DNS records
+       are encountered in the record set for the apex and a GNS2DNS record
+       is expicitly requested by the application, such records MUST
+       still be returned, even if DNS support is disabled by the
+       GNS resolver configuration.
+     </t>
          </section>
          <section anchor="cname_processing" numbered="true" toc="default">
            <name>CNAME</name>
@@ -1033,8 +1033,8 @@
              In order to prevent infinite loops, the resolver MUST
              implement loop detections or limit the number of recursive
              resolution steps.
-            <!-- Note: Martin: do we actually implement this in GNS today? 
-                 Seems rather tricky to detect if we go via NSS... -->
+       <!-- Note: Martin: do we actually implement this in GNS today? 
+      Seems rather tricky to detect if we go via NSS... -->
            </t>
          </section>
          <section anchor="box_processing" numbered="true" toc="default">
@@ -1051,7 +1051,7 @@
          <section anchor="vpn_processing" numbered="true" toc="default">
            <name>VPN</name>
            <t>
-            At the end of the recursion,
+       At the end of the recursion,
              if the queried record type is either A or AAAA and the retrieved
              record set contains at least one VPN record, the resolver SHOULD
              open a tunnel and return the IPv4 or IPv6 tunnel address,
@@ -1102,12 +1102,23 @@
        </t>
        <figure>
        <artwork name="" type="" align="left" alt=""><![CDATA[
-         skey := kdf_scrypt (salt="gnunet-revocation-proof-of-work", REVDAT)
-         skey_iv := iv_derive (salt="gnunet-revocation-proof-of-work", 
"gnunet-proof-of-work-iv", skey)
-         enc := AES (skey, skey_iv, REVDAT)
-         REV := kdf_scrypt(salt="gnunet-revocation-proof-of-work", enc)
+         DK := scrypt (P := REV)
+         IV := IVderive (salt="gnunet-revocation-proof-of-work", 
"gnunet-proof-of-work-iv", DK)
+         EREV := AES (DK, IV, REV) /* TODO this is more complex */
+         REVDATA := scrypt(P := enc)
+         ]]></artwork>
+        </figure>
+     <t>
+       where "scrypt" is the scrypt algorithm as defined in
+       <xref target="RFC7914" /> with the following parameters set:
+     </t>
+       <artwork name="" type="" align="left" alt=""><![CDATA[
+         S := "gnunet-revocation-proof-of-work" /* Salt */
+         N := 1 /* CPU memory cost parameter TODO spec says >1!!! */
+         r := 8 /* Block size */
+         p := 2 /* Parallelization parameter */
+         dkLen := 512 /* Intended output length */
          ]]></artwork>
-     </figure>
      <t>
        The above function is called with different values for the "NONCE" in
        "REVDAT" until the amount of leading zeroes is greater or equal 25.
@@ -1122,7 +1133,7 @@
          which 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.
+   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
          discretion of the local system administrator or user.
@@ -1132,14 +1143,14 @@
          where root zone governance is centralized at the Internet Corporation
          for Assigned Names and Numbers (ICANN).
          In DNS terminology, GNS roughly follows the idea of a hyper-hyper
-        local root zone deployment, with the difference that it is not
-        expected that all deployments use the same local root zone.
+   local root zone deployment, with the difference that it is not
+   expected that all deployments use the same local root zone.
        </t>
        <t>
          In the following, we give examples how a local client resolver SHOULD
          discover the start zone.  The process given is not exhaustive and
          clients MAY suppliement it with other mechanisms or ignore it if the
-        particular application requires a different process.
+   particular application requires a different process.
        </t>
        <t>
          GNS clients SHOULD first try to interpret the top-level domain of
@@ -1156,11 +1167,11 @@
        <t>
          In GNS, users MAY own and manage their own zones.
          Each local zone SHOULD be associated with a single GNS label,
-        but users MAY choose to use longer names consisting of
-        multiple labels.
+   but users MAY choose to use longer names consisting of
+   multiple labels.
          If the name of a locally managed zone matches the suffix
-        of the name to be resolved,
-        resolution SHOULD start from the respective local zone:
+   of the name to be resolved,
+   resolution SHOULD start from the respective local zone:
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
          Example name: www.example.gnu
@@ -1180,8 +1191,8 @@
          ".". 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 a locally managed zone and a configuration entry exist
-        for the same suffix, the locally managed zone MUST have priority.
+   If both a locally managed zone and a configuration entry exist
+   for the same suffix, the locally managed zone MUST have priority.
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
          Example name: www.example.gnu
@@ -1343,7 +1354,25 @@
            <date year="1999" month="March"/>
          </front>
        </reference>
-
+       <reference anchor="RFC7914" 
target="https://www.rfc-editor.org/info/rfc7914";>
+         <front>
+           <title>The scrypt Password-Based Key Derivation Function</title>
+           <author initials="C." surname="Percival" fullname="C. Percival">
+             <organization/>
+           </author>
+           <author initials="S." surname="Josefsson" fullname="S. Josefsson">
+             <organization/>
+           </author>
+           <date year="2016" month="August"/>
+           <abstract>
+             <t>
+               This document specifies the password-based key derivation 
function scrypt. The function derives one or more secret keys from a secret 
string. It is based on memory-hard functions, which offer added protection 
against attacks using custom hardware. The document also provides an ASN.1 
schema.
+             </t>
+           </abstract>
+         </front>
+         <seriesInfo name="RFC" value="7914"/>
+         <seriesInfo name="DOI" value="10.17487/RFC7914"/>
+       </reference>
        <!--    <reference anchor="ISO20022">
          <front>
          <title>ISO 20022 Financial Services - Universal financial industry 
message scheme</title>

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



reply via email to

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