[lsd0001] branch master updated: review with bfix

[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 41437cd  review with bfix
41437cd is described below

commit 41437cd20299d6c7c6b90841e143e338bd8b5440
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Fri Feb 4 19:01:05 2022 +0100

    review with bfix
---
 draft-schanzen-gns.xml | 165 +++++++++++++++++++++++++++++--------------------
 1 file changed, 98 insertions(+), 67 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 26d0d70..640e135 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -190,7 +190,7 @@
          A GNS label is a label as defined in <xref target="RFC8499"/>.
          Within this document, labels are always assumed to be strings of
          UTF-8 characters <xref target="RFC8499"/> with a maximum length of
-         63 bytes.  When hashed, labels MUST be canonicalized using
+         63 bytes. Labels MUST be canonicalized using
          Normalization Form C (NFC) <xref target="Unicode-UAX15"/>.
        </dd>
        <dt>Name</dt>
@@ -200,7 +200,7 @@
          The labels in a name are separated using the character "." (dot).
          Names, like labels, are encoded in UTF-8.
        </dd>
-       <dt>Top-Level Domain</dt>
+       <dt>Top-Level Domain</dt> <!--FIXME shall we call this TLZ? -->
        <dd>
         The rightmost part of a GNS name is a GNS Top-Level Domain (TLD).
          A GNS TLD may consist of one or more labels.
@@ -395,6 +395,9 @@
        <dd>
          is a function to sign a message (typically encrypted record data) 
using the (blinded) private
          key d (d'), yielding an unforgable cryptographic signature.
+         In order to leverage performance-enhancing caching features of certain
+         underlying storages, in particular DHTs, a deterministic signature
+         scheme is recommended.
        </dd>
        <dt>Verify(zk,message,signature) -> boolean, 
Verify(zk',message,signature) -> boolean</dt>
        <dd>
@@ -497,6 +500,7 @@ ztype|zkey := GNSCrockfordDecode(zkl)
          to subsequently determine how many labels the zTLD should span.
          For example, assuming a zkl of 130 characters, the encoding would be:
        </t>
+       <!-- FIXME: Is this really really necessary? Really? -->
        <artwork name="" type="" align="left" alt=""><![CDATA[
 zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
        ]]></artwork>
@@ -694,10 +698,12 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
            (see <xref target="zones" />).
          </dd>
        </dl>
+       <!-- FIXME Do we really need a purpose? -->
       <t>
-         The signature over the public key covers a 32-bit pseudo header
-         conceptually prefixed to the public key. The pseudo header includes
-        the key length and signature purpose. The wire format is illustrated
+        The signature over the public key covers a 32-bit header
+        prefixed to the timestamp and public key fields.
+        The header includes the key length and signature purpose.
+        The wire format is illustrated
         in <xref target="figure_revsigwithpseudo"/>.
        </t>
        <figure anchor="figure_revsigwithpseudo">
@@ -767,7 +773,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
      <name>Resource Records</name>
      <t>
        A GNS implementer SHOULD provide a mechanism to create and manage 
resource
-       records for local zones.  A local zone is established by selecting a
+       records for local zones.  A new local zone is established by selecting a
        zone type and creating a zone key pair.
        As records may be added to each zone by its owner, a (local) persistence
        mechanism such as a database for resource records and zones SHOULD be 
provided.
@@ -822,7 +828,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
        </dd>
        <dt>DATA</dt>
        <dd>
-         the variable-length resource record data payload. The contents are 
defined
+         the variable-length resource record data payload. The content is 
defined
          by the
          respective type of the resource record.
        </dd>
@@ -886,20 +892,23 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
        MAY BE a valid choice if some zone delegation record types have been
        determined to be cryptographically insecure, or if an application has
        reasons to not support delegation to DNS for reasons such as complexity
-       or security.  Zone delegation records MUST NOT be stored and published
-       under the empty label.
+       or security. Zone delegation records MUST NOT be stored and published
+         under the empty label.
+     <!-- FIXME: Empty label and apex label are not well defined -->
+       A zone delegation record type value is the same as the respective ztype
+       value.
+       The ztype defines the cryptographic primitives for the zone that is
+       being delegated to.
+       A zone delegation resource record payload contains the public key of
+       the zone to delegate to.
+       A zone delegation record MUST be the only record under a label.
+       No other records are allowed.
      </t>
      <section anchor="gnsrecords_pkey" numbered="true" toc="default">
        <name>PKEY</name>
-       <t>In GNS, a delegation of a label to a zone of type "PKEY" is
-         represented through a PKEY record.  The PKEY number is a ztype
-         and thus also implies the cryptosystem for the zone that
-         is being delegated to.
-         A PKEY resource record contains the public key of the zone to
-         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
-         in <xref target="figure_pkeyrecord"/>.
+       <t>
+         In GNS, a delegation of a label to a zone of type "PKEY" is
+         represented through a PKEY record.  The PKEY DATA entry wire format 
can be found in <xref target="figure_pkeyrecord"/>.
        </t>
        <figure anchor="figure_pkeyrecord">
          <artwork name="" type="" align="left" alt=""><![CDATA[
@@ -916,14 +925,14 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
        <dl>
          <dt>PUBLIC KEY</dt>
          <dd>
-           A 256-bit ECDSA zone key.
+           A 256-bit Ed25519 public key.
          </dd>
        </dl>
 
        <t>
          For PKEY zones the zone key material is derived using the
-         curve parameters of the twisted edwards representation
-         of Curve25519 <xref target="RFC7748" /> (a.k.a. edwards25519)
+         curve parameters of the twisted Edwards representation
+         of Curve25519 <xref target="RFC7748" /> (a.k.a. Ed25519)
          with the ECDSA scheme <xref target="RFC6979" />.
          Consequently, we use the following naming convention for our
          cryptographic primitives for PKEY zones:
@@ -931,11 +940,11 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
        <dl>
          <dt>d</dt>
          <dd>
-           is a 256-bit ECDSA private key.
+           is a 256-bit Ed25519 private key (private scalar).
          </dd>
          <dt>zk</dt>
          <dd>
-           is the ECDSA public zone key corresponding to d.
+           is the Ed25519 public zone key corresponding to d.
          </dd>
          <dt>p</dt>
          <dd>
@@ -959,7 +968,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
          </dd>
        </dl>
        <t>
-         The zone type and zone key of a PKEY are 32 + 4 bytes in length. This 
means that
+         The zone type and zone key of a PKEY are 4 + 32 bytes in length. This 
means that
          a zTLD will always fit into a single label and does
          not need any further conversion.
        </t>
@@ -1061,23 +1070,30 @@ S-Encrypt(zk,label,expiration,message):
   K := HKDF-Expand (PRK_k, label, 256 / 8);
   NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
   IV := NONCE | expiration | 0x0000000000000001
-  CIPHERTEXT := CTR-AES256(K, IV, DATA)
-  DATA := CTR-AES256(K, IV, CIPHERTEXT)
+  return CTR-AES256(K, IV, DATA)
            ]]></artwork>
        </figure>
        <t>The PKEY S-Encrypt Procedure.</t>
+       <figure anchor="figure_sdec_pkey">
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+S-Decrypt(zk,label,expiration,ciphertext):
+  PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
+  PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk)
+  K := HKDF-Expand (PRK_k, label, 256 / 8);
+  NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
+  IV := NONCE | expiration | 0x0000000000000001
+  return CTR-AES256(K, IV, ciphertext)
+           ]]></artwork>
+       </figure>
+       <t>The PKEY S-Decrypt Procedure.</t>
+       <!-- FIXME: Explicit precedures would be nicer Appendix?-->
      </section>
      <section anchor="gnsrecords_edkey" numbered="true" toc="default">
        <name>EDKEY</name>
        <t>
          In GNS, a delegation of a label to a zone of type "EDKEY" is
-         represented through a EDKEY record.  The EDKEY number is a
-         ztype and thus also implies the cryptosystem for the zone that
-         is being delegated to.
-         An EDKEY resource record contains the public key of the zone to
-         delegate to.
-         A EDKEY record MUST be the only record under a label. No other
-           records are allowed. The EDKEY DATA entry wire format
+         represented through a EDKEY record.
+         The EDKEY DATA entry wire format
          is illustrated in <xref target="figure_edkeyrecord"/>.
        </t>
        <figure anchor="figure_edkeyrecord">
@@ -1101,11 +1117,12 @@ S-Encrypt(zk,label,expiration,message):
          <t>
            For EDKEY zones the zone key material is derived using the
            curve parameters of the twisted edwards representation
-           of Curve25519 <xref target="RFC7748" /> (a.k.a. edwards25519)
+           of Curve25519 <xref target="RFC7748" /> (a.k.a. Ed25519)
            with the Ed25519-SHA-512 scheme <xref target="ed25519" />.
            Consequently, we use the following naming convention for our
            cryptographic primitives for EDKEY zones:
          </t>
+         <!-- Check if we want to use RFC8032 instead of paper ed25519 -->
          <dl>
            <dt>d</dt>
            <dd>
@@ -1149,7 +1166,7 @@ S-Encrypt(zk,label,expiration,message):
             </dd>
          </dl>
          <t>
-           The zone type and zone key of an EDKEY are 32 + 4 bytes in length. 
This means that
+           The zone type and zone key of an EDKEY are 4 + 32 bytes in length. 
This means that
            a zTLD will always fit into a single label and does
            not need any further conversion.
          </t>
@@ -1163,9 +1180,9 @@ zk := a * G
 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 */
+a1 := a >> 3
 a2 := (h * a1) mod L
-a' = a2 * 8 /* 8 is the cofactor of Curve25519 */
+a' = a2 << 3
            ]]></artwork>
          <t>
            Equally, given a label, the output of the ZKDF-Public function is
@@ -1182,9 +1199,10 @@ zk' := h * zk
            multiplication for the constructions above to protect against
            timing attacks. Otherwise, timing attacks may leak private key
            material if an attacker can predict when a system starts the
-           publication process. Also, implementers
+           publication process.
+           <!--Also, implementers
            MUST ensure that the private key a is an ed25519 private key
-           and specifically that "a[0] &#38; 7 == 0" holds.
+           and specifically that "a[0] &#38; 7 == 0" holds.-->
          </t>
          <t>
            The EDKEY cryptosystem uses a
@@ -1222,6 +1240,10 @@ zk' := h * zk
            of the R value of the signature, ensuring that it is never reused
            for two different derivation paths or messages.
          </t>
+         <!-- Blinded key signatures need a different method signature
+           FIXME Should we use a'
+           nonce := SHA-256 (a')?
+         -->
          <artwork name="" type="" align="left" alt=""><![CDATA[
 dh := SHA-512 (d)
 nonce := SHA-256 (dh[32..63] | h)
@@ -1504,6 +1526,8 @@ NONCE := HKDF-Expand (PRK_n, label, 128 / 8)
        <dl>
          <dt>PROTO</dt>
          <dd>
+           <!-- FIXME: Help Christian this is all wrong.
+           RFC6895 is DNS. Also: SVC what are possible numbers? -->
            the 16-bit protocol number, e.g. 6 for tcp.
            Note that values
            below 2^8 are reserved for allocation via IANA <xref 
target="RFC6895" />,
@@ -1792,7 +1816,10 @@ q := SHA-512 (ZKDF-Public(zk, label))
      </t>
      <t>
        When GNS name resolution is requested, a desired record type MAY be
-       provided by the client.
+       provided by the client to guide processing.
+       <!-- FIXME: Is this still necessary? Clarify the purpose of the
+       provided record type and normatively define that resolver MUST NOT
+       filter? -->
        However, filtering of record sets according to the required record
        types MUST still be done by the client after the resource record set
        is retrieved.
@@ -1800,10 +1827,11 @@ q := SHA-512 (ZKDF-Public(zk, label))
      <section anchor="governance" numbered="true" toc="default">
        <name>Start Zones</name>
        <t>
+         <!-- FIXME: This is a mess -->
          The resolution of a GNS name must start in a given start zone
-         indicated to the resolution algorithm using any (public) zone key.
+         indicated to the resolution algorithm using a (public) zone key.
          The local resolver may have one or more local start zones 
configured/hard-coded
-         which point to a local or remote start zone public keys.
+         which point to local or remote zone public keys.
          A resolver may also determine the start zone from the
          suffix of the name given for resolution, or using information
          retrieved out of band.
@@ -1824,9 +1852,8 @@ q := SHA-512 (ZKDF-Public(zk, label))
        <t>
          GNS clients MUST first try to interpret the top-level domain of
          a GNS name as a zone key representation (i.e. a zTLD).
-         If the top-level domain is indicated to be a representation of
-         a zone key with a supported zone type value, the start zone of
-         the resolution process is implicitly given by the suffix of the name:
+         If the top-level domain can be converted to a valid ztype and zone
+         key value, the resulting zone key is used as the start zone:
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 Example name: www.example.<zTLD>
@@ -1909,9 +1936,9 @@ example.com = zk2
          <name>Record Processing</name>
          <t>
            Record processing occurs once a well-formed block was decrypted.
-           In record processing, only the valid records thus
-           obtained are considered.  To filter records by validity, the 
resolver
-           MUST at least checking the expiration time and the FLAGS of the
+           In record processing, only the valid records obtained are 
considered.
+           To filter records by validity, the resolver
+           MUST at least check the expiration time and the FLAGS of the
            respective record.  In particular, FLAGS may exclude shadow and
            supplemental records from being considered.
            If the resolver encounters a record with the CRITICAL flag set and
@@ -2079,11 +2106,10 @@ example.com = zk2
              If the remainder of the name to resolve is empty and we have
              received a record set containing only a single delegation record, 
the
              recursion is continued with the record value as authoritative zone
-             and the empty apex label "@" as remaining name, except in the case
-             where the desired record type as specified by the client
-             is equal to the ztype, in which
-             case the delegation record is returned and the resolution is 
concluded without
-             resolving the empty apex label.
+             and the empty apex label "@" as remaining name.
+             Except in the case where the desired record type as specified by
+             the client is equal to the ztype, in which case the delegation
+             record is returned.
            </t>
          </section>
          <section anchor="nick_processing" numbered="true" toc="default">
@@ -2142,6 +2168,8 @@ NICK: john (Supplemental)
        <name>Internationalization and Character Encoding</name>
        <t>
          All labels in GNS are encoded in UTF-8 <xref target="RFC3629" />.
+         Labels MUST be canonicalized using
+         Normalization Form C (NFC) <xref target="Unicode-UAX15"/>.
          This does not include any DNS names found in DNS records, such as 
CNAME
          records, which are internationalized through the IDNA specifications
          <xref target="RFC5890" />.
@@ -2184,7 +2212,7 @@ NICK: john (Supplemental)
          </t>
          <t>
            This document concerns itself with the selection of cryptographic
-           algorithms for use in GNS.
+           algorithms used in GNS.
            The algorithms identified in this document are not known to be
            broken (in the cryptographic sense) at the current time, and
            cryptographic research so far leads us to believe that they are
@@ -2195,7 +2223,7 @@ NICK: john (Supplemental)
          </t>
          <t>
            In terms of crypto-agility, whenever the need for an updated 
cryptographic
-           scheme arises to, for example, replace ECDSA over Curve25519 for
+           scheme arises to, for example, replace ECDSA over Ed25519 for
            PKEY records it may simply be introduced
            through a new record type. Such a new record type may then replace
            the delegation record type for future records.
@@ -2210,14 +2238,14 @@ NICK: john (Supplemental)
        <section anchor="security_cryptography" numbered="true" toc="default">
          <name>Cryptography</name>
          <t>
-           GNS PKEY zone keys use ECDSA over Curve25519.
+           GNS PKEY zone keys use ECDSA over Ed25519.
            This is an unconventional choice,
            as ECDSA is usually used with other curves.  However, traditional
            ECDSA curves are problematic for a range of reasons described in
            the Curve25519 and EdDSA papers.  Using EdDSA directly is also
            not possible, as a hash function is used on the private key which
            destroys the linearity that the GNU Name System depends upon.
-           We are not aware of anyone suggesting that using Curve25519 instead
+           We are not aware of anyone suggesting that using Ed25519 instead
            of another common curve of similar size would lower the security of
            ECDSA.  GNS uses 256-bit curves because that way the encoded 
(public)
            keys fit into a single DNS label, which is good for usability.
@@ -2225,7 +2253,7 @@ NICK: john (Supplemental)
          <t>
            In order to ensure ciphertext indistinguishability, care must be
            taken with respect to the initialization vector in the counter
-           block. In our design, the IV is always the expiration time of the
+           block. In our design, the IV always includes the expiration time of 
the
            record block.
            When applications store records with relative expiration times,
            monotonicity is implicitly
@@ -2284,8 +2312,8 @@ NICK: john (Supplemental)
            required to responsibly and diligently protect their cryptographic
            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.
+           <!-- It does not support separate zone signing and key-signing keys
+           (as in <xref target="RFC6781" />) in order to provide usable 
security. This is not useful for any implementer -->
          </t>
          <t>
            Similarly, users are required to manage their local start zone 
configuration.
@@ -2353,7 +2381,7 @@ NICK: john (Supplemental)
          </t>
          <ol>
            <li>
-           If revocation is used after a private key was compromised,
+           If a revocation is published after a private key was compromised,
            allowing key replacement would be dangerous: if an
            adversary took over the private key, the adversary could then
            broadcast a revocation with a key replacement. For the replacement,
@@ -2377,7 +2405,7 @@ NICK: john (Supplemental)
        <section anchor="privacy_labels" numbered="true" toc="default">
          <name>Label Guessing</name>
          <t>
-           Record blocks are published encrypted using keys derived from the
+           Record blocks are published in encrypted form using keys derived 
from the
            zone key and record label. Zone administrators should
            carefully consider if the label and zone key may be public or if
            those should be used and considered as a shared secret.
@@ -2404,8 +2432,8 @@ NICK: john (Supplemental)
        <name>GANA Considerations</name>
        <t>
          GANA <xref target="GANA" />
-         is requested to create an "GNU Name System Record Types" registry.
-         The registry shall record for each entry:
+         manages the "GNU Name System Record Types" registry.
+         Each entry has the following format:
        </t>
        <ul>
          <li>Name: The name of the record type (case-insensitive ASCII
@@ -2420,12 +2448,15 @@ NICK: john (Supplemental)
            (such as an RFC)</li>
        </ul>
        <t>
-         The registration policy for this sub-registry is "First Come First
+         The registration policy for this registry is "First Come First
          Served". This policy is modeled on that described in <xref 
target="RFC8126"/>,
-         but describes the actions taken by GANA.
+         and describes the actions taken by GANA:
        </t>
        <t>
-         Adding records is possible after expert review, using a
+         <!-- FIXME: Unclear who are the experts how are they selected and
+         by whom? GNUnet e.V. Politbüro? The DAO?
+         Unreserved/Reserved for private use record type range? -->
+         Adding new records is possible after expert review, using a
          first-come-first-served policy for unique name allocation.
          Experts are responsible to ensure that the chosen "Name" is
          appropriate for the record type.

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