[lsd0001] branch master updated: try to fix signatures

[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 a000871  try to fix signatures
a000871 is described below

commit a000871fddb6d29af43f532fde21fe743fd17251
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Tue Feb 8 20:21:23 2022 +0100

    try to fix signatures
---
 draft-schanzen-gns.xml | 115 ++++++++++++++++++++++++++-----------------------
 1 file changed, 62 insertions(+), 53 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index df41a8e..2c54320 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -192,8 +192,10 @@
          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. Labels MUST be canonicalized using
-           Normalization Form C (NFC) <xref target="Unicode-UAX15"/>.
+         63 bytes for compatibility with applications enforcing DNS legacy
+         limitations.
+         Labels MUST be canonicalized using
+         Normalization Form C (NFC) <xref target="Unicode-UAX15"/>.
        </dd>
        <dt>Apex Label</dt>
        <dd>
@@ -201,7 +203,7 @@
          quotes).
          The apex label is used to publish resource
          records in a zone that can be resolved without providing a specific
-         name. It is the GNS method to provide what is the "zone apex" in DNS
+         label. It is the GNS method to provide what is the "zone apex" in DNS
          <xref target="RFC4033"/>.
        </dd>
        <dt>Name</dt>
@@ -269,17 +271,10 @@
          A GNS resource record contains information as defined by its
          resource record type.
        </dd>
-       <dt>Client</dt>
-       <dd>
-         The client is an implementation component which facilitates
-         zone management and name resolution.
-         It enables the user to manage zones (<xref target="publish"/>) and
-         resolve names (<xref target="resolution"/>).
-       </dd>
        <dt>Application</dt>
        <dd>
          An application refers to a component which uses a GNS implementation
-         to resolve records from the network and (usually) processes its 
contents.
+         to resolve names into records and processes its contents.
        </dd>
      </dl>
    </section>
@@ -358,8 +353,7 @@
        Each zone can be represented by a Zone Top-Level Domain (zTLD) string.
      </t>
      <t>
-       <!-- FIXME: MUST or SHOULD? Was must reformulated SHOULD -->
-       A client implementation SHOULD enable the user to create and manage 
zones.
+       A implementation SHOULD enable the user to create and manage zones.
        If this functionality is not implemented, names can still be resolved
        if zone keys for the initial step in the name resolution are available
        (see <xref target="resolution"/>).
@@ -419,7 +413,7 @@
          data based on key material derived from the zone key,
          a label, and an expiration timestamp.
        </dd>
-       <dt>Sign(d,message) -> signature, Sign(d',message) -> signature</dt>
+       <dt>Sign(d,message) -> signature, SignDerived(d,label,message) -> 
signature</dt>
        <dd>
          is a function to sign a message (typically encrypted record data) 
using the (blinded) private
          key d (d'), yielding an unforgeable cryptographic signature.
@@ -427,7 +421,7 @@
          underlying storages, in particular DHTs, a deterministic signature
          scheme is recommended.
        </dd>
-       <dt>Verify(zk,message,signature) -> boolean, 
Verify(zk',message,signature) -> boolean</dt>
+       <dt>Verify(zk,message,signature) -> boolean, 
VerifyDerived(zk,label,message,signature) -> boolean</dt>
        <dd>
          is a function to verify the signature was created by
          the private key d (or derived key d') corresponding to
@@ -1040,8 +1034,21 @@ ZKDF-Public(zk,label)
          The Sign() and Verify() functions
          for PKEY zones are implemented using 512-bit ECDSA deterministic
          signatures as specified in <xref target="RFC6979" />.
-         The same functions can be used for derived keys.
+         The same functions can be used for derived keys:
        </t>
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+SignDerived(d,label,message):
+  d' := ZKDF-Private(d,label)
+  return Sign(d',message)
+           ]]></artwork>
+         <t>
+           A signature (R,S) is valid if the following holds:
+         </t>
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+VerifyDerived(zk,label,message,signature):
+  zk' := ZKDF-Public(zk,label)
+  return Verify(zk',message,signature)
+           ]]></artwork>
        <t>
          The S-Encrypt() and S-Decrypt() functions use AES in counter mode
          as defined in <xref target="MODES" /> (CTR-AES-256):
@@ -1191,22 +1198,24 @@ S-Decrypt(zk,label,expiration,ciphertext):
          </t>
          <t>
            The "EDKEY" ZKDF instantiation is based on <xref target="Tor224"/>.
-           For brevity, instead of using d as a parameter to the derivation,
-           we define the ZKDF-Private() procedure on the derived integer a.
            The calculation of a is defined in Section 5.1.5 of <xref 
target="RFC8032" />.
            Given a label, the output of the ZKDF-Private function for zone
            key blinding is calculated as follows for EDKEY zones:
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
-ZKDF-Private(a,label):
+ZKDF-Private(d,label):
+  a := SHA-512 (d)
+  a[0] &= 248;
+  a[31] &= 127;
+  a[31] |= 64;
   zk := a * G
   PRK_h := HKDF-Extract ("key-derivation", zk)
   h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
   h[31] &= 7
   a1 := a >> 3
   a2 := (h * a1) mod L
-  a' = a2 << 3
-  return a'
+  d' := a2 << 3
+  return d'
            ]]></artwork>
          <t>
            Equally, given a label, the output of the ZKDF-Public function is
@@ -1216,7 +1225,7 @@ ZKDF-Private(a,label):
 ZKDF-Public(zk,label):
   PRK_h := HKDF-Extract ("key-derivation", zk)
   h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
-  h[31] &= 7  // Implies h mod L == h
+  h[31] &= 7
   zk' := h * zk
   return zk'
            ]]></artwork>
@@ -1256,9 +1265,9 @@ ZKDF-Public(zk,label):
            be implemented as defined in <xref target="RFC8032" />.
          </t>
          <t>
-           Signatures for EDKEY zones using the derived private key a'
+           Signatures for EDKEY zones using the derived private scalar d'
            are not compliant with <xref target="RFC8032" />.
-           As the corresponding private key to the derived private scalar a'
+           As the corresponding private key to the derived private scalar d'
            is not known, it is not possible to deterministically derive the
            signature part R according to <xref target="RFC8032" />.
            Instead, signatures MUST be generated as follows for any given
@@ -1270,24 +1279,22 @@ ZKDF-Public(zk,label):
            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')? Changed for now. Unclear if ok.
-         -->
          <artwork name="" type="" align="left" alt=""><![CDATA[
-Sign(d,message):
+SignDerived(d,label,message):
+  d' := ZKDF-Private(d,label)
   dh := SHA-512 (d)
   nonce := SHA-256 (dh[32..63] | h)
   r := SHA-512 (nonce | message)
   R := r * G
-  S := r + SHA-512(R | zk' | message) * a' mod L
+  S := r + SHA-512(R | zk' | message) * d' mod L
   return (R,S)
            ]]></artwork>
          <t>
            A signature (R,S) is valid if the following holds:
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
-Verify(zk',message,signature):
+VerifyDerived(zk,label,message,signature):
+  zk' := ZKDF-Public(zk,label)
   (R,S) := signature
   return S * G == R + SHA-512(R, zk', message) * zk'
            ]]></artwork>
@@ -1410,6 +1417,8 @@ S-Decrypt(zk,label,expiration,ciphertext):
          in DNS followed by a DNS server. Both names are in the format defined 
in
          <xref target="RFC1034" /> for DNS names.
          There MAY be multiple GNS2DNS records under a label.
+         There MAY also be DNSSEC DS records or any other records used to
+         secure the connection with the DNS servers under the same label.
          No other record types are allowed in the same record set.
          A GNS2DNS DATA entry is illustrated in <xref 
target="figure_gns2dnsrecord"/>.</t>
        <figure anchor="figure_gns2dnsrecord">
@@ -1592,7 +1601,8 @@ S-Decrypt(zk,label,expiration,ciphertext):
          </dd>
          <dt>SVC</dt>
          <dd>
-           the 16-bit service value of the boxed record, i.e. the port number.
+           the 16-bit service value of the boxed record. In case of
+           TCP and UDP it is the port number.
            In network byte order.
          </dd>
          <dt>TYPE</dt>
@@ -1869,21 +1879,14 @@ q := SHA-512 (ZKDF-Public(zk, label))
        <xref target="governance" />.
      </t>
      <t>
-       <!-- FIXME removed client everywhere. We only have an implementation -->
-       The client implementation MAY allow the user to provide a desired
-       record type for the resolver.
+       The application MAY provide a desired record type to the resolver.
        The desired record type is used to guide processing.
-       For example, if zone delegation record type is requested, the
-       resolution of the apex label in that zone may not be necessary, as
+       For example, if a zone delegation record type is requested, the
+       resolution of the apex label in that zone must be skipped, as
        the desired record is already found.
-       <!-- FIXME: Is this still necessary? Clarify the purpose of the
-       provided record type and normatively define that resolver MUST NOT
-       filter? THe normative statement for the CLIENT does not make sense.
-       We need a normative statement for the implementer of GNS. -->
        The resolver implementation MUST NOT filter results according to the 
desired
        record type.
-       Filtering of record sets MAY still be done by the client which
-       could be a stub resolver.
+       Filtering of record sets is typically done by the application.
      </t>
      <section anchor="governance" numbered="true" toc="default">
        <name>Start Zones</name>
@@ -1892,7 +1895,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
          or only the client? Because the resolver needs to know the zones for
          redirects, for example -->
          The resolution of a GNS name starts in an initial start zone.
-         The local resolver may have one or more local start zones configured
+         The resolver may have one or more local start zones configured
          which point to local or remote zone keys.
          A resolver may also determine the start zone from the
          suffix of the name given for resolution, or using information
@@ -1908,9 +1911,9 @@ q := SHA-512 (ZKDF-Public(zk, label))
          management of root servers in DNS (see <xref target="RFC8324"/>, 
Section 3.10 and 3.12).
        </t>
         <t>
-         In the following, we give examples how a local client SHOULD
+         In the following, we give examples how a resolver SHOULD
          discover the start zone.  The process given is not exhaustive and
-         clients MAY supplement it with other mechanisms or ignore it if the
+         resolvers MAY supplement it with other mechanisms or ignore it if the
          particular application requires a different process.
        </t>
        <t>
@@ -2106,6 +2109,12 @@ example.com = zk2
              identical for all of them, if not the resolution fails and an
              appropriate error is SHOULD be returned to the application.
            </t>
+           <t>
+             If there are DNSSEC DS records or any other records used to
+             secure the connection with the DNS servers stored under the label,
+             the DNS resolver SHOULD use them to secure the connection with
+             the DNS server.
+           </t>
            <t>
              Once the IP addresses of the DNS servers have been determined,
              the DNS name from the GNS2DNS record is appended
@@ -2115,7 +2124,7 @@ example.com = zk2
              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.
+             is returned to the application.
              In addition, the resolver SHOULD return the queried DNS name as a
              supplemental LEHO record (see <xref target="gnsrecords_leho" />) 
with a
              relative expiration time of one hour.
@@ -2139,7 +2148,7 @@ example.com = zk2
              still be returned, even if DNS support is disabled by the
              GNS resolver configuration.
            </t>
-           <!-- FIXME: Loop detection -->
+           <!-- FIXME: State the DNS resolution never "returns" to GNS. -->
          </section>
          <section anchor="box_processing" numbered="true" toc="default">
            <name>BOX</name>
@@ -2176,7 +2185,7 @@ example.com = zk2
              recursion is continued with the record value as authoritative zone
              and the 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
+             the application is equal to the ztype, in which case the 
delegation
              record is returned.
            </t>
          </section>
@@ -2185,7 +2194,7 @@ example.com = zk2
            <t>
              NICK 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 encountered NICK records may either
+             be returned to the application. The encountered NICK records may 
either
              be supplemental (see <xref target="rrecords"/>) or
              non-supplemental.
              If the NICK record is supplemental, the resolver only returns the
@@ -2196,7 +2205,7 @@ example.com = zk2
            </t>
            <t>
              The differentiation between a supplemental and non-supplemental
-             NICK record allows the client to match the record to the
+             NICK record allows the application to match the record to the
              authoritative zone. Consider the following example:
            </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
@@ -2207,7 +2216,7 @@ NICK: eve (non-Supplemental)
          ]]></artwork>
         <t>
           In this example, the returned NICK record is non-supplemental.
-          For the client, this means that the NICK belongs to the zone
+          For the application, this means that the NICK belongs to the zone
           "alice.example" and is published under the apex label along with an A
           record. The NICK record should be interpreted as: The zone defined by
           "alice.example" wants to be referred to as "eve".
@@ -2596,7 +2605,7 @@ Purpose | Name            | References | Comment
          is an active deployment of GNS on top of its <xref target="R5N"/>
          DHT. The <xref target="GoGNS"/> implementation uses this deployment
          by building on top of the GNUnet DHT services available on any
-         GNUnet peer. It shows how GNS implementations and client resolvers
+         GNUnet peer. It shows how GNS implementations
          can attach to this existing deployment and participate in name
          resolution as well as zone publication.
        </t>

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