commit f8411eeb01cae6314bd89276e9c1867e0bec1f1e
parent 140861cbb9ce2b1ab7be6ab162715332dc652b59
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Wed, 16 Feb 2022 20:42:15 +0100
pow
Diffstat:
1 file changed, 35 insertions(+), 28 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -650,12 +650,20 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
<dt>TTL</dt>
<dd>
denotes the relative 64-bit time to live of the record in
- microseconds also in network byte order. This field is informational
- for a verifier. A verifier MAY discard a revocation without
+ microseconds also in network byte order.
+ The field SHOULD be set to EPOCH * 1.1.
+ If the average number of leading zeros D' is larger than
+ D, then the field value MAY be increased up to
+ (D'-D) * EPOCH * 1.1.
+ The EPOCH is extended by
+ 10% in order to deal with unsynchronized clocks.
+ This field is informational for a verifier.
+ A verifier MAY discard a revocation without
checking the POW values or the signature if the TTL (in combination with TIMESTAMP)
- indicates that the revocation has already expired. However, the actual TTL of the
- revocation must be determined by examining the leading zeroes in the
- proof of work calculation.
+ indicates that the revocation has already expired.
+ The actual validity period of the
+ revocation MUST be determined by examining the leading zeroes in the
+ POW values.
</dd>
<dt>POW_i</dt>
<dd>
@@ -743,17 +751,18 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
<li>The average number of leading zeroes D' resulting from the provided
POW values MUST be greater than and not equal to D. Implementers
MUST NOT use an integer data type to calculate or represent D'.</li>
- <li>The validation period (TTL) of the revocation is calculated as
+ <li>
+ The validity period 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.
- Should the verifier calculate the TTL and find that it differs from
- the field value, the verifier MUST continue and
+ The validity period added on top of the TIMESTAMP yields the
+ expiration date.
+ Should the verifier calculate the validity and find that it differs from
+ the TTL field value, the verifier MUST continue and
use the calculated value when forwarding the revocation.
</li>
<li>The current time SHOULD be between TIMESTAMP and
- TIMESTAMP+TTL. Implementations MAY process the revocation without validating this.</li>
+ TIMESTAMP + validity period. Implementations MAY process the revocation without validating this.</li>
</ol>
</section>
@@ -1017,7 +1026,6 @@ VerifyDerived(zk,label,message,signature):
The S-Encrypt() and S-Decrypt() functions use AES in counter mode
as defined in <xref target="MODES" /> (CTR-AES-256):
</t>
- <figure anchor="figure_senc_pkey" title="The PKEY S-Encrypt Procedure.">
<artwork name="" type="" align="left" alt=""><![CDATA[
S-Encrypt(zk,label,expiration,plaintext):
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
@@ -1026,10 +1034,7 @@ S-Encrypt(zk,label,expiration,plaintext):
NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
IV := NONCE || expiration || 0x0000000000000001
return CTR-AES256(K, IV, plaintext)
- ]]></artwork>
- </figure>
- <figure anchor="figure_sdec_pkey" title="The PKEY S-Decrypt Procedure.">
- <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)
@@ -1038,7 +1043,6 @@ S-Decrypt(zk,label,expiration,ciphertext):
IV := NONCE || expiration || 0x0000000000000001
return CTR-AES256(K, IV, ciphertext)
]]></artwork>
- </figure>
<t>
The key K and counter IV are derived from
the record label and the zone key zk using a hash-based key
@@ -1570,7 +1574,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
<dl>
<dt>PROTO</dt>
<dd>
- the 16-bit protocol number, e.g. 6 for tcp.
+ the 16-bit protocol number, e.g. 6 for TCP.
Note that values
below 2^8 are reserved for allocation via IANA <xref target="RFC5237" />,
while values above 2^8 are allocated by the
@@ -1667,7 +1671,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
supplemental flag set (See <xref target="rrecords"/>).
The contained resource records are encrypted using a symmetric
encryption scheme.
- A GNS implementation publish RRBLOCKs
+ A GNS implementation publishes RRBLOCKs
in accordance to the properties and recommendations of the underlying
storage. This may include a periodic refresh operation to ensure the
availability of the published RRBLOCKs.
@@ -1700,14 +1704,15 @@ q := SHA-512 (ZKDF-Public(zk, label))
<dl>
<dt>SIZE</dt>
<dd>
- A 32-bit value containing the length of the block.
+ A 32-bit value containing the length of the block in bytes.
+ In network byte order.
While a 32-bit value is used,
implementations MAY refuse to publish blocks beyond a certain
size significantly below 4 GB.
</dd>
<dt>ZONE TYPE</dt>
<dd>
- is the 32-bit ztype.
+ is the 32-bit ztype. In network byte order.
</dd>
<dt>ZONE KEY</dt>
<dd>
@@ -1981,7 +1986,7 @@ example.com = zk2
<section anchor="record_processing" numbered="true" toc="default">
<name>Record Processing</name>
<t>
- Record processing occurs once a well-formed block was decrypted.
+ Record processing occurs once a well-formed block has been decrypted.
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
@@ -2295,7 +2300,7 @@ NICK: john (Supplemental)
<t>
GNS PKEY zone keys use ECDSA over Ed25519.
This is an unconventional choice,
- as ECDSA is usually used with other curves. However, traditional
+ as ECDSA is usually used with other curves. However, standardized
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
@@ -2425,7 +2430,7 @@ NICK: john (Supplemental)
Zone administrators are advised to pre-generate zone revocations
and to securely store the revocation information in case the zone
key is lost, compromised or replaced in the future.
- Pre-calculated revocations may become invalid due to expirations
+ Pre-calculated revocations may cease to be valid due to expirations
or protocol changes such as epoch adjustments.
Consequently, implementers and users must take precautions in order
to manage revocations accordingly.
@@ -2529,8 +2534,9 @@ NICK: john (Supplemental)
as a descriptive comment as defined above.
</t>
<t>
- GANA is requested to populate this registry as listed in
- <xref target="figure_rrtypenums"/>.
+ GANA has assigned numbers for the record types defined in this
+ specification in the "GNU Name System Record Types" registry
+ as listed in <xref target="figure_rrtypenums"/>.
</t>
<figure anchor="figure_rrtypenums" title="The GANA Resource Record Registry.">
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -2546,8 +2552,9 @@ Number | Name | Contact | References | Comment
]]></artwork>
</figure>
<t>
- GANA is requested to amend the "GNUnet Signature Purpose" registry
- as illustrated in <xref target="figure_purposenums"/>.
+ GANA has assigned signature purposes in its
+ "GNUnet Signature Purpose" registry as listed in
+ <xref target="figure_purposenums"/>.
</t>
<figure anchor="figure_purposenums" title="Requested Changes in the GANA GNUnet Signature Purpose Registry.">
<artwork name="" type="" align="left" alt=""><