gnunet-svn
[Top][All Lists]
Advanced

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

[lsd0001] branch master updated: move revocation


From: gnunet
Subject: [lsd0001] branch master updated: move revocation
Date: Tue, 21 Dec 2021 16:25:55 +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 e05b093  move revocation
e05b093 is described below

commit e05b093608f7af0192c3727538ccab7647b916c8
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Tue Dec 21 16:25:51 2021 +0100

    move revocation
---
 draft-schanzen-gns.xml | 483 +++++++++++++++++++++++++------------------------
 1 file changed, 242 insertions(+), 241 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index ff6e2b2..641894b 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1309,6 +1309,248 @@ q := SHA512 (HDKD-Public(zk, label))
        </dl>
      </section>
    </section>
+     <section anchor="revocation" numbered="true" toc="default">
+       <name>Zone Revocation</name>
+       <t>
+         Whenever a recursive resolver encounters a new GNS zone, it MUST
+         check against the local revocation list whether the respective
+         zone key has been revoked.  If the zone key was revoked, the
+         resolution MUST fail with an empty result set.
+       </t>
+       <t>
+         In order to revoke a zone key, a signed revocation object MUST be
+         published.
+         This object MUST be signed using the private zone key.
+         The revocation object is flooded in the overlay network. To prevent
+         flooding attacks, the revocation message MUST contain a proof of work
+         (PoW).
+         The revocation message including the PoW MAY be calculated
+         ahead of time to support timely revocation.
+       </t>
+       <t>
+         For all occurences below, "Argon2id" is the Password-based Key
+         Derivation Function as defined in <xref target="RFC9106" />. For the
+         PoW calculations the algorithm is instantiated with the
+         following parameters:
+       </t>
+       <dl>
+         <dt>S</dt>
+         <dd>The salt. Fixed 16-byte string: "GnsRevocationPow".</dd>
+         <dt>t</dt>
+         <dd>Number of iterations: 3</dd>
+         <dt>m</dt>
+         <dd>Memory size in KiB: 1024</dd>
+         <dt>T</dt>
+         <dd>Output length of hash in bytes: 64</dd>
+         <dt>p</dt>
+         <dd>Parallelization parameter: 1</dd>
+         <dt>v</dt>
+         <dd>Algorithm version: 0x13</dd>
+         <dt>y</dt>
+         <dd>Algorithm type (Argon2id): 2</dd>
+         <dt>X</dt><dd>Unused</dd>
+         <dt>K</dt><dd>Unused</dd>
+       </dl>
+       <t>
+         <xref target="figure_revocation"/> illustrates the wire format
+         of the message string "P" on which the PoW is calculated.
+       </t>
+       <figure anchor="figure_revocation">
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+0     8     16    24    32    40    48    56
++-----+-----+-----+-----+-----+-----+-----+-----+
+|                      POW                      |
++-----------------------------------------------+
+|                   TIMESTAMP                   |
++-----------------------------------------------+
+|       ZONE TYPE       |    PUBLIC ZONE KEY    |
++-----+-----+-----+-----+                       |
+/                                               /
+/                                               /
++-----+-----+-----+-----+-----+-----+-----+-----+
+           ]]></artwork>
+       </figure>
+       <t>The Wire Format of the PoW Message String.</t>
+       <dl>
+         <dt>POW</dt>
+         <dd>
+           A 64-bit solution to the PoW. In network byte order.
+         </dd>
+         <dt>TIMESTAMP</dt>
+         <dd>
+           denotes the absolute 64-bit date when the revocation was computed.
+           In microseconds since midnight (0 hour), January 1, 1970 in network
+           byte order.
+         </dd>
+         <dt>PUBLIC KEY</dt>
+         <dd>
+           is the 256-bit public key zk of the zone which is being revoked and
+           the key to be used to verify SIGNATURE. The
+           wire format of this value is defined in <xref target="RFC8032" />,
+           Section 5.1.5.
+         </dd>
+       </dl>
+       <t>
+         Traditionally, PoW schemes require to find a POW such that
+         at least D leading zeroes are found in the hash result.
+         D is then referred to as the difficulty of the PoW.
+         In order to reduce the variance in time it takes to calculate the
+         PoW, we require that a number Z different PoWs must be
+         found that on average have D leading zeroes.
+       </t>
+       <t>
+         The resulting proofs may then published and disseminated. The concrete
+         dissemination and publication methods are out of scope of this
+         document. Given an average difficulty of D, the proofs have an
+         expiration time of EPOCH. With each additional bit difficulty, the
+         lifetime of the proof is prolonged for another EPOCH.
+         Consequently, by calculating a more difficult PoW, the lifetime of the
+         proof can be increased on demand by the zone owner.
+       </t>
+       <t>
+         The parameters are defined as follows:
+       </t>
+       <dl>
+         <dt>Z</dt>
+         <dd>The number of PoWs required is fixed at 32.</dd>
+         <dt>D</dt>
+         <dd>The difficulty is fixed at 22.</dd>
+         <dt>EPOCH</dt>
+         <dd>A single epoch is fixed at 365 days.</dd>
+       </dl>
+       <t>
+         The revocation message wire format is illustrated in 
+         <xref target="figure_revocationdata"/>.
+       </t>
+       <figure anchor="figure_revocationdata">
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+0     8     16    24    32    40    48    56
++-----+-----+-----+-----+-----+-----+-----+-----+
+|                   TIMESTAMP                   |
++-----+-----+-----+-----+-----+-----+-----+-----+
+|                      TTL                      |
++-----+-----+-----+-----+-----+-----+-----+-----+
+|                     POW_0                     |
++-----+-----+-----+-----+-----+-----+-----+-----+
+|                       ...                     |
++-----+-----+-----+-----+-----+-----+-----+-----+
+|                     POW_Z-1                   |
++-----------------------------------------------+
+|       ZONE TYPE       |    PUBLIC ZONE KEY    |
++-----+-----+-----+-----+                       |
+/                                               /
+/                                               /
++-----+-----+-----+-----+-----+-----+-----+-----+
+|                   SIGNATURE                   |
+/                                               /
+/                                               /
+|                                               |
++-----+-----+-----+-----+-----+-----+-----+-----+
+           ]]></artwork>
+       </figure>
+       <t>The Revocation Message Wire Format.</t>
+       <dl>
+         <dt>TIMESTAMP</dt>
+         <dd>
+           denotes the absolute 64-bit date when the revocation was computed.
+           In microseconds since midnight (0 hour), January 1, 1970 in network
+           byte order. This is the same value as the timestamp used in the
+           individual PoW calculations.
+         </dd>
+         <dt>TTL</dt>
+         <dd>
+           denotes the relative 64-bit time to live of 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
+           revocation must be determined by examining the leading zeros in the
+           proof of work calculation.
+         </dd>
+         <dt>POW_i</dt>
+         <dd>
+           The values calculated as part of the PoW, in network byte order.
+           Each POW_i MUST be unique in the set of POW values.
+           To facilitate fast verification
+           of uniqueness, the POW values must be given in strictly
+           monotonically increasing order in the message.
+         </dd>
+         <dt>ZONE TYPE</dt>
+         <dd>
+           The 32-bit zone type corresponding to the zone public key.
+         </dd>
+         <dt>ZONE PUBLIC KEY</dt>
+         <dd>
+           is the public key zk of the zone which is being revoked and
+           the key to be used to verify SIGNATURE.
+         </dd>
+         <dt>SIGNATURE</dt>
+         <dd>
+           A signature over a timestamp and the public zone zk of the zone
+           which is revoked and corresponds to the key used in the PoW.
+           The signature is created using the Sign() function of
+           the cryptosystem of the zone and the private zone key
+           (see <xref target="zone_types" />).
+         </dd>
+       </dl>
+      <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
+        in <xref target="figure_revsigwithpseudo"/>.
+       </t>
+       <figure anchor="figure_revsigwithpseudo">
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+0     8     16    24    32    40    48    56
++-----+-----+-----+-----+-----+-----+-----+-----+
+|         SIZE (0x30)   |       PURPOSE (0x03)  |
++-----+-----+-----+-----+-----+-----+-----+-----+
+|                   TIMESTAMP                   |
++-----+-----+-----+-----+-----+-----+-----+-----+
+|       ZONE TYPE       |     ZONE PUBLIC KEY   |
++-----+-----+-----+-----+                       |
+/                                               /
+/                                               /
++-----+-----+-----+-----+-----+-----+-----+-----+
+           ]]></artwork>
+       </figure>
+       <t>The Wire Format of the Revocation Data for Signing.</t>
+       <dl>
+         <dt>SIZE</dt>
+         <dd>
+           A 32-bit value containing the length of the signed data in bytes
+           in network byte order.
+         </dd>
+         <dt>PURPOSE</dt>
+         <dd>
+           A 32-bit signature purpose flag. This field MUST be 3 (in network
+           byte order).
+         </dd>
+         <dt>ZONE TYPE</dt>
+         <dd>
+           The 32-bit zone type corresponding to the zone public key.
+         </dd>
+         <dt>ZONE PUBLIC KEY / TIMESTAMP</dt>
+         <dd>Both values as defined in the revocation data object above.</dd>
+       </dl>
+       <t>
+         In order to verify a revocation the following steps must be taken,
+         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>
+         <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>
+       </ol>
+     </section>
+
    <section anchor="resolution" numbered="true" toc="default">
      <name>Name Resolution</name>
      <t>
@@ -1666,247 +1908,6 @@ NICK: john (Supplemental)
          </section>
        </section>
      </section>
-     <section anchor="revocation" numbered="true" toc="default">
-       <name>Zone Revocation</name>
-       <t>
-         Whenever a recursive resolver encounters a new GNS zone, it MUST
-         check against the local revocation list whether the respective
-         zone key has been revoked.  If the zone key was revoked, the
-         resolution MUST fail with an empty result set.
-       </t>
-       <t>
-         In order to revoke a zone key, a signed revocation object MUST be
-         published.
-         This object MUST be signed using the private zone key.
-         The revocation object is flooded in the overlay network. To prevent
-         flooding attacks, the revocation message MUST contain a proof of work
-         (PoW).
-         The revocation message including the PoW MAY be calculated
-         ahead of time to support timely revocation.
-       </t>
-       <t>
-         For all occurences below, "Argon2id" is the Password-based Key
-         Derivation Function as defined in <xref target="RFC9106" />. For the
-         PoW calculations the algorithm is instantiated with the
-         following parameters:
-       </t>
-       <dl>
-         <dt>S</dt>
-         <dd>The salt. Fixed 16-byte string: "GnsRevocationPow".</dd>
-         <dt>t</dt>
-         <dd>Number of iterations: 3</dd>
-         <dt>m</dt>
-         <dd>Memory size in KiB: 1024</dd>
-         <dt>T</dt>
-         <dd>Output length of hash in bytes: 64</dd>
-         <dt>p</dt>
-         <dd>Parallelization parameter: 1</dd>
-         <dt>v</dt>
-         <dd>Algorithm version: 0x13</dd>
-         <dt>y</dt>
-         <dd>Algorithm type (Argon2id): 2</dd>
-         <dt>X</dt><dd>Unused</dd>
-         <dt>K</dt><dd>Unused</dd>
-       </dl>
-       <t>
-         <xref target="figure_revocation"/> illustrates the wire format
-         of the message string "P" on which the PoW is calculated.
-       </t>
-       <figure anchor="figure_revocation">
-         <artwork name="" type="" align="left" alt=""><![CDATA[
-0     8     16    24    32    40    48    56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-|                      POW                      |
-+-----------------------------------------------+
-|                   TIMESTAMP                   |
-+-----------------------------------------------+
-|       ZONE TYPE       |    PUBLIC ZONE KEY    |
-+-----+-----+-----+-----+                       |
-/                                               /
-/                                               /
-+-----+-----+-----+-----+-----+-----+-----+-----+
-           ]]></artwork>
-       </figure>
-       <t>The Wire Format of the PoW Message String.</t>
-       <dl>
-         <dt>POW</dt>
-         <dd>
-           A 64-bit solution to the PoW. In network byte order.
-         </dd>
-         <dt>TIMESTAMP</dt>
-         <dd>
-           denotes the absolute 64-bit date when the revocation was computed.
-           In microseconds since midnight (0 hour), January 1, 1970 in network
-           byte order.
-         </dd>
-         <dt>PUBLIC KEY</dt>
-         <dd>
-           is the 256-bit public key zk of the zone which is being revoked and
-           the key to be used to verify SIGNATURE. The
-           wire format of this value is defined in <xref target="RFC8032" />,
-           Section 5.1.5.
-         </dd>
-       </dl>
-       <t>
-         Traditionally, PoW schemes require to find a POW such that
-         at least D leading zeroes are found in the hash result.
-         D is then referred to as the difficulty of the PoW.
-         In order to reduce the variance in time it takes to calculate the
-         PoW, we require that a number Z different PoWs must be
-         found that on average have D leading zeroes.
-       </t>
-       <t>
-         The resulting proofs may then published and disseminated. The concrete
-         dissemination and publication methods are out of scope of this
-         document. Given an average difficulty of D, the proofs have an
-         expiration time of EPOCH. With each additional bit difficulty, the
-         lifetime of the proof is prolonged for another EPOCH.
-         Consequently, by calculating a more difficult PoW, the lifetime of the
-         proof can be increased on demand by the zone owner.
-       </t>
-       <t>
-         The parameters are defined as follows:
-       </t>
-       <dl>
-         <dt>Z</dt>
-         <dd>The number of PoWs required is fixed at 32.</dd>
-         <dt>D</dt>
-         <dd>The difficulty is fixed at 22.</dd>
-         <dt>EPOCH</dt>
-         <dd>A single epoch is fixed at 365 days.</dd>
-       </dl>
-       <t>
-         The revocation message wire format is illustrated in 
-         <xref target="figure_revocationdata"/>.
-       </t>
-       <figure anchor="figure_revocationdata">
-         <artwork name="" type="" align="left" alt=""><![CDATA[
-0     8     16    24    32    40    48    56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-|                   TIMESTAMP                   |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-|                      TTL                      |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-|                     POW_0                     |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-|                       ...                     |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-|                     POW_Z-1                   |
-+-----------------------------------------------+
-|       ZONE TYPE       |    PUBLIC ZONE KEY    |
-+-----+-----+-----+-----+                       |
-/                                               /
-/                                               /
-+-----+-----+-----+-----+-----+-----+-----+-----+
-|                   SIGNATURE                   |
-/                                               /
-/                                               /
-|                                               |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-           ]]></artwork>
-       </figure>
-       <t>The Revocation Message Wire Format.</t>
-       <dl>
-         <dt>TIMESTAMP</dt>
-         <dd>
-           denotes the absolute 64-bit date when the revocation was computed.
-           In microseconds since midnight (0 hour), January 1, 1970 in network
-           byte order. This is the same value as the timestamp used in the
-           individual PoW calculations.
-         </dd>
-         <dt>TTL</dt>
-         <dd>
-           denotes the relative 64-bit time to live of 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
-           revocation must be determined by examining the leading zeros in the
-           proof of work calculation.
-         </dd>
-         <dt>POW_i</dt>
-         <dd>
-           The values calculated as part of the PoW, in network byte order.
-           Each POW_i MUST be unique in the set of POW values.
-           To facilitate fast verification
-           of uniqueness, the POW values must be given in strictly
-           monotonically increasing order in the message.
-         </dd>
-         <dt>ZONE TYPE</dt>
-         <dd>
-           The 32-bit zone type corresponding to the zone public key.
-         </dd>
-         <dt>ZONE PUBLIC KEY</dt>
-         <dd>
-           is the public key zk of the zone which is being revoked and
-           the key to be used to verify SIGNATURE.
-         </dd>
-         <dt>SIGNATURE</dt>
-         <dd>
-           A signature over a timestamp and the public zone zk of the zone
-           which is revoked and corresponds to the key used in the PoW.
-           The signature is created using the Sign() function of
-           the cryptosystem of the zone and the private zone key
-           (see <xref target="zone_types" />).
-         </dd>
-       </dl>
-      <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
-        in <xref target="figure_revsigwithpseudo"/>.
-       </t>
-       <figure anchor="figure_revsigwithpseudo">
-         <artwork name="" type="" align="left" alt=""><![CDATA[
-0     8     16    24    32    40    48    56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-|         SIZE (0x30)   |       PURPOSE (0x03)  |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-|                   TIMESTAMP                   |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-|       ZONE TYPE       |     ZONE PUBLIC KEY   |
-+-----+-----+-----+-----+                       |
-/                                               /
-/                                               /
-+-----+-----+-----+-----+-----+-----+-----+-----+
-           ]]></artwork>
-       </figure>
-       <t>The Wire Format of the Revocation Data for Signing.</t>
-       <dl>
-         <dt>SIZE</dt>
-         <dd>
-           A 32-bit value containing the length of the signed data in bytes
-           in network byte order.
-         </dd>
-         <dt>PURPOSE</dt>
-         <dd>
-           A 32-bit signature purpose flag. This field MUST be 3 (in network
-           byte order).
-         </dd>
-         <dt>ZONE TYPE</dt>
-         <dd>
-           The 32-bit zone type corresponding to the zone public key.
-         </dd>
-         <dt>ZONE PUBLIC KEY / TIMESTAMP</dt>
-         <dd>Both values as defined in the revocation data object above.</dd>
-       </dl>
-       <t>
-         In order to verify a revocation the following steps must be taken,
-         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>
-         <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>
-       </ol>
-     </section>
      <section anchor="encoding" numbered="true" toc="default">
        <name>Internationalization and Character Encoding</name>
        <t>

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



reply via email to

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