commit e05b093608f7af0192c3727538ccab7647b916c8
parent 6700414feb683725d184dbfc77be1972bc8d3cac
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Tue, 21 Dec 2021 16:25:51 +0100
move revocation
Diffstat:
1 file changed, 242 insertions(+), 241 deletions(-)
diff --git 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>
