[lsd0001] branch master updated: djb feedback

[gnunet]

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 8734677  djb feedback
8734677 is described below

commit 8734677f64d00f16091915485f21b4051f533903
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Mon Jan 17 00:12:32 2022 +0100

    djb feedback
---
 draft-schanzen-gns.xml | 75 +++++++++++++++++++++++++-------------------------
 1 file changed, 38 insertions(+), 37 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 9e2980b..1319dfc 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -139,8 +139,8 @@
        This is an important distinguishing factor from the Domain Name System
        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
+       In DNS terminology, GNS roughly follows the idea of a hyperlocal root
+       zone deployment, with the difference that it is not
        expected that all deployments use the same local root zone.
      </t>
      <t>
@@ -168,9 +168,10 @@
      <t>
        In GNS, any user may create and manage one or more cryptographically
        secured zones (<xref target="zones"/>).
-       A set of cryptographic functions which are determined by the zone type
-       enable the creation of signatures for zone contents using blinded
-       public/private key pairs and encryption of zone contents.
+       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.
      </t>
      <t>
        A zone can be populated with mappings from labels
@@ -278,7 +279,7 @@
        </dd>
        <dt>S-Encrypt(zk,label,nonce,expiration,message) -> ciphertext</dt>
        <dd>
-         is a deterministic symmetric encryption function which encrypts the 
record
+         is a symmetric encryption function which encrypts the record
          data based on key material derived from the zone key,
          a label, a nonce and an expiration.
          In order to leverage performance-enhancing caching features of certain
@@ -287,9 +288,9 @@
        </dd>
        <dt>S-Decrypt(zk,label,nonce,expiration,ciphertext) -> message</dt>
        <dd>
-         is a symmetric encryption function which decrypts the encrypted record
+         is a symmetric decryption function which decrypts the encrypted record
          data based on key material derived from the zone key,
-         a label, a nonce an expiration.
+         a label, a nonce and an expiration.
        </dd>
        <dt>Sign(d',message) -> signature</dt>
        <dd>
@@ -299,7 +300,7 @@
        <dt>Verify(zk',message,signature) -> valid</dt>
        <dd>
          is a function to verify the signature was created by
-         the a private key d' derived from d and a label if
+         the private key d' derived from d and a label if
          zk' was derived from the corresponding zone key
          zk := Public-Keygen(d) and same label.
          The function returns a boolean value of "TRUE" if the signature is 
valid,
@@ -404,7 +405,7 @@ zid := GNSCrockfordDecode(zkl)
          For example, assuming a zkl of 130 characters, the encoding would be:
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
-zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
+zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
        ]]></artwork>
    </section>
     <section anchor="revocation" numbered="true" toc="default">
@@ -494,8 +495,7 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
          <dt>ZONE KEY</dt>
          <dd>
            is the 256-bit public key zk of the zone which is being revoked.
-           The wire format of this value is defined in <xref target="RFC8032" 
/>,
-           Section 5.1.5.
+           The wire format of this value is defined by the ZONE TYPE.
          </dd>
        </dl>
        <t>
@@ -567,7 +567,7 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
          </dd>
          <dt>TTL</dt>
          <dd>
-           denotes the relative 64-bit time to live of of the record in
+           denotes the relative 64-bit time to live of the record in
            microseconds also in network byte order. This field is informational
            for a verifier. The verifier may discard revocation if the TTL
            indicates that it is already expired. However, the actual TTL of the
@@ -645,17 +645,17 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
          in order:
        </t>
        <ol>
-         <li>The current time MUST be between TIMESTAMP and
-           TIMESTAMP+TTL.</li>
          <li>The signature MUST match the public key.</li>
          <li>The set of POW values MUST NOT contain duplicates.</li>
          <li>The average number of leading zeroes resulting from the provided
-           POW values D' MUST be greater than D.</li>
+           POW values D' MUST be greater than and not equal to D.</li>
          <li>The validation period (TTL) of the revocation is calculated as
            (D'-D) * EPOCH * 1.1. The EPOCH is extended by
            10% in order to deal with unsynchronized clocks.
            The TTL added on top of the TIMESTAMP yields the
            expiration date.</li>
+         <li>The current time MUST be between TIMESTAMP and
+           TIMESTAMP+TTL.</li>
        </ol>
      </section>
 
@@ -803,7 +803,7 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
          delegate to.
          A PKEY record MUST be the only record under a label. No other
          records are allowed. The PKEY DATA entry wire format can be found
-         found in <xref target="figure_pkeyrecord"/>.
+         in <xref target="figure_pkeyrecord"/>.
        </t>
        <figure anchor="figure_pkeyrecord">
          <artwork name="" type="" align="left" alt=""><![CDATA[
@@ -857,7 +857,7 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
          </dd>
          <dt>L</dt>
          <dd>
-           is the prime-order subgroup of edwards25519 in <xref 
target="RFC7748" />.
+           is the order of the prime-order subgroup of edwards25519 in <xref 
target="RFC7748" />.
          </dd>
        </dl>
        <t>
@@ -873,7 +873,7 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
 zk := d * G
 PRK_h := HKDF-Extract ("key-derivation", zk)
 h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
-d' := h * d mod L
+d' := (h * d) mod L
         ]]></artwork>
        <t>
          Equally, given a label, the output zk' of the ZKDF-Public(zk,label) 
function is
@@ -882,7 +882,7 @@ d' := h * d mod L
          <artwork name="" type="" align="left" alt=""><![CDATA[
 PRK_h := HKDF-Extract ("key-derivation", zk)
 h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
-zk' := h mod L * zk
+zk' := (h mod L) * zk
         ]]></artwork>
        <t>
          The PKEY cryptosystem uses a hash-based key derivation function 
(HKDF) as defined in
@@ -909,8 +909,8 @@ zk' := h mod L * zk
          as defined in <xref target="MODES" /> (CTR-AES-256):
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
-DATA := CTR-AES256(K, IV, CIPHERTEXT)
 CIPHERTEXT := CTR-AES256(K, IV, DATA)
+DATA := CTR-AES256(K, IV, CIPHERTEXT)
          ]]></artwork>
        <t>
          The key K and counter IV are derived from
@@ -1028,7 +1028,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
            </dd>
            <dt>L</dt>
            <dd>
-             is the prime-order subgroup of edwards25519 in <xref 
target="RFC7748" />.
+             is the order of the prime-order subgroup of edwards25519 in <xref 
target="RFC7748" />.
            </dd>
          </dl>
          <t>
@@ -1047,7 +1047,7 @@ PRK_h := HKDF-Extract ("key-derivation", zk)
 h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
 h[31] &= 7
 a1 := a / 8 /* 8 is the cofactor of Curve25519 */
-a2 := h * a1 mod L
+a2 := (h * a1) mod L
 a' = a2 * 8 /* 8 is the cofactor of Curve25519 */
            ]]></artwork>
          <t>
@@ -1121,13 +1121,13 @@ S * G == R + SHA512(R, zk', M) * zk'
            (XSalsa20-Poly1305):
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
-DATA := XSalsa20(K, IV, CIPHERTEXT)
-CIPHERTEXT := XSalsa20(K, IV, DATA) = CIPHERTEXT | TAG
+CIPHERTEXT := XSalsa20-Poly1305(K, IV, DATA)
+DATA := XSalsa20-Poly1305(K, IV, CIPHERTEXT)
            ]]></artwork>
          <t>
-           The result of the XSalsa20 encryption function is the encrypted
+           The result of the XSalsa20-Poly1305 encryption function is the 
encrypted
            ciphertext concatenated with the 128-bit authentication
-           tag TAG.
+           tag.
            Accordingly, the length of encrypted data equals the length of the
            data plus the 16 bytes of the authentication tag.
          </t>
@@ -1363,8 +1363,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
          The GNUnet Tunnel Service record is used by
          applications to establish a tunnel between two peers in the
          peer-to-peer network (see <xref target="GNUnet"/>).
-         In order to facilitate the use of such tunnels, the
-         The GTS record serves as an example to how resolvers may automatically
+         The GTS record serves as an example of how resolvers may automatically
          initiate tunnel establishment and provide IP address information in 
the
          resolution process as specified in <xref target="resolution"/>.
        </t>
@@ -1631,7 +1630,8 @@ q := SHA512 (HDKD-Public(zk, label))
      <t>
        Names in GNS are resolved by recursively querying the record storage.
        Recursive in this context means that a resolver does not provide
-       iterative results for a query (as is the case with iterative DNS 
resolution).
+       iterative results for a query.
+       <!--(as is the case with iterative DNS resolution). REMOVED -->
        Instead, it MUST respond to a resolution request with either the
        requested resource record or an error message in case the resolution
        fails.
@@ -1641,7 +1641,7 @@ q := SHA512 (HDKD-Public(zk, label))
      <t>
        GNS resolution of a name must start in a given starting zone indicated 
using
        a zone key.
-       Details on how the starting zone may be determined is discussed in
+       Details on how the starting zone may be determined are discussed in
        <xref target="governance" />.
      </t>
      <t>
@@ -1862,7 +1862,7 @@ example.com = zk2
              to the remainder of the name to be resolved, and
              resolved by querying the DNS name server(s).  As the DNS servers
              specified are possibly authoritative DNS servers, the GNS 
resolver MUST
-             support recursive resolution and MUST NOT delegate this to the
+             support recursive DNS resolution and MUST NOT delegate this to the
              authoritative DNS servers.
              The first successful recursive name resolution result
              is returned to the client.
@@ -1961,9 +1961,9 @@ NICK: eve
         <t>
           In this example, the returned NICK record is non-supplemental.
           For the client, this means that the NICK belongs to the zone
-          "alice.doe" and is published under the empty label along with an A
+          "alice.example" and is published under the empty label along with an 
A
           record. The NICK record should be interpreted as: The zone defined by
-          "alice.doe" wants to be referred to as "eve".
+          "alice.example" wants to be referred to as "eve".
           In contrast, consider the following:
         </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
@@ -2055,7 +2055,7 @@ NICK: john (Supplemental)
            monotonically.
            For blocks with absolute expiration times, the implementation
            MUST ensure that the expiration time is modified when the record
-           data changes. For example. the expiration time may be increased
+           data changes. For example, the expiration time may be increased
            by a single microsecond.
          </t>
        </section>
@@ -2088,8 +2088,9 @@ NICK: john (Supplemental)
            pre-calculated and is still available).
            Zone administrators, and for GNS this includes end-users, are
            required to responsibly and diligently protect their cryptographic
-           keys.  Offline signing is in principle possible, but GNS does not
-           support separate zone signing and key-signing keys
+           keys.
+           GNS supports offline signing of records.
+           It does not support separate zone signing and key-signing keys
            (as in <xref target="RFC6781" />) in order to provide usable 
security.
          </t>
          <t>

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