lsd0001

commit e39403b58cebad40281c9b3fce4e0bf998832f9c
parent 45a9ee5665f31e9a16d6d88cd2993f47e8d4895d
Author: Christian Grothoff <christian@grothoff.org>
Date:   Fri,  4 Oct 2019 23:13:02 +0200

minor fixes

Diffstat:
M
draft-schanzen-gns.xml
 | 
44
+++++++++++++++++++++++++++++++-------------

1 file changed, 31 insertions(+), 13 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -403,10 +403,10 @@
        published together in a single block in the DHT.
        A resource records block is published under a key "q" which is derived
        from the zone key "zk" and the respective label of the contained records.
-       Given a label, the DHT key "q" is derived as follows:
      </t>
      <section anchor="blinding" numbered="true" toc="default">
        <name>Key derivations</name>
+       Given a label, the DHT key "q" is derived as follows:
        <artwork name="" type="" align="left" alt=""><![CDATA[
          PRK_h := HKDF-Extract ("key-derivation", zk)
          h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
@@ -461,6 +461,8 @@
            derived private key "d_h".
          </dd>
        </dl>
+       We point out that the multiplication of "zk" with "h" is a point multiplication,
+       while the multiplication of "d" with "h" is a scalar multiplication.
      </section>
      <section anchor="wire" numbered="true" toc="default">
        <name>Resource records block</name>
@@ -520,7 +522,11 @@
            A 32-bit value containing the length of the signed data following the
            PUBLIC KEY field in network byte order. This value always includes the
            length of the fields SIZE (4), PURPOSE (4) and EXPIRATION (8) in
-           addition to the length of the BDATA.
+           addition to the length of the BDATA.  While a 32-bit value is used,
+           implementations MAY refuse to publish blocks beyond a certain
+           size significantly below 4 GB. However, a minimum block size of
+           62 kilobytes MUST be supported.
+           <!-- See GNUNET_CONSTANTS_MAX_BLOCK_SIZE -->
          </dd>
          <dt>PURPOSE</dt>
          <dd>
@@ -529,11 +535,13 @@
          </dd>
          <dt>EXPIRATION</dt>
          <dd>
-           is the 64-bit resource records block expiration time. This is the
-           expiration
-           time of the resource record contained within this block with the
+           Specifies when the resource records block expires and the encrypted block
+           SHOULD be removed from the DHT and caches as it is likely stale.
+           However, applications MAY continue to use non-expired individual
+           records until they expire.  The value MUST be set to the
+           expiration time of the resource record contained within this block with the
            smallest expiration time.
-           If a records block includes shadow records, then the *maximum*
+           If a records block includes shadow records, then the maximum
            expiration time of all shadow records with matching type and the
            expiration times of the non-shadow records is considered.
            This is a 64-bit absolute date in microseconds since midnight
@@ -587,7 +595,13 @@
            A 32-bit value containing the number of variable-length resource
            records which are
            following after this field in network byte order.
-           The resource record format is defined in <xref target="rrecords" />.
+         </dd>
+         <dt>EXPIRATION, DATA SIZE, TYPE, FLAGS and DATA</dt>
+         <dd>
+           These fields were defined
+           in the resource record format in <xref target="rrecords" />.
+           There MUST be a total of RR COUNT of these resource records
+           present.
          </dd>
          <dt>PADDING</dt>
          <dd>
@@ -600,16 +614,20 @@
 
        </dl>
        <t>
-         Upon receiving a resource records block, first the validity of a
-         given "zk_h" MUST be checked by computing the expected "zk_h" from "zk"
-         and label (as defined in <xref target="blinding" />) and verifying that
-         both are equal. This step is mandatory to prevent record spoofing.
+         To obtain a given resource records block, the client must first compute
+         "zk_h" from "zk"
+         and label (as defined in <xref target="blinding" />)
+         and then use "zk_h" to compute "q" which is the query for the DHT.
+         Upon receiving a block from the DHT, the receiver first checks
+         that the PUBLIC KEY field matches "zk_h".  Then, the client MUST verify
+         the signature. These steps are mandatory to prevent record spoofing and
+         MUST be performed before decryption.
        </t>
        <t>
          The symmetric keys and initialization vectors are derived from the
          record label and the zone key "zk". For decryption of the resource
          records block payload, the key material "K" and initialization vector
-         "IV" for the symmetric en-/decryption are derived as follows:
+         "IV" for the symmetric cipher are derived as follows:
        </t>
        <!-- OLD VERSION
        PRK_kiv := HKDF-Extract (zk, label)
@@ -628,7 +646,7 @@
          extraction phase and HMAC-SHA256 for the expansion phase.
          The output keying material is 64 octets (512 bit) for the symmetric
          keys and 32 octets (256 bit) for the initialization vectors.
-         We divide the resulting keying material "K" into a 256-bit AES 
+         We divide the resulting keying material "K" into a 256-bit AES
          <xref target="RFC3826" /> key
          and a 256-bit TWOFISH <xref target="TWOFISH" /> key:
        </t>