commit 8734677f64d00f16091915485f21b4051f533903
parent 3cd40a4d0603b9d6e7de52d92b22f22222b29dc6
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Mon, 17 Jan 2022 00:12:32 +0100
djb feedback
Diffstat:
1 file changed, 38 insertions(+), 37 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -139,8 +139,8 @@
This is an important distinguishing factor from the Domain Name System
where root zone governance is centralized at the Internet Corporation
for Assigned Names and Numbers (ICANN).
- In DNS terminology, GNS roughly follows the idea of a hyper-hyper
- local root zone deployment, with the difference that it is not
+ In DNS terminology, GNS roughly follows the idea of a hyperlocal root
+ zone deployment, with the difference that it is not
expected that all deployments use the same local root zone.
</t>
<t>
@@ -168,9 +168,10 @@
<t>
In GNS, any user may create and manage one or more cryptographically
secured zones (<xref target="zones"/>).
- A set of cryptographic functions which are determined by the zone type
- enable the creation of signatures for zone contents using blinded
- public/private key pairs and encryption of zone contents.
+ Zones are uniquely identified by a zone key.
+ Zone contents are signed using blinded private keys and
+ encrypted using derived secret keys.
+ The zone type determines the respectice set of cryptographic functions.
</t>
<t>
A zone can be populated with mappings from labels
@@ -278,7 +279,7 @@
</dd>
<dt>S-Encrypt(zk,label,nonce,expiration,message) -> ciphertext</dt>
<dd>
- is a deterministic symmetric encryption function which encrypts the record
+ is a symmetric encryption function which encrypts the record
data based on key material derived from the zone key,
a label, a nonce and an expiration.
In order to leverage performance-enhancing caching features of certain
@@ -287,9 +288,9 @@
</dd>
<dt>S-Decrypt(zk,label,nonce,expiration,ciphertext) -> message</dt>
<dd>
- is a symmetric encryption function which decrypts the encrypted record
+ is a symmetric decryption function which decrypts the encrypted record
data based on key material derived from the zone key,
- a label, a nonce an expiration.
+ a label, a nonce and an expiration.
</dd>
<dt>Sign(d',message) -> signature</dt>
<dd>
@@ -299,7 +300,7 @@
<dt>Verify(zk',message,signature) -> valid</dt>
<dd>
is a function to verify the signature was created by
- the a private key d' derived from d and a label if
+ the private key d' derived from d and a label if
zk' was derived from the corresponding zone key
zk := Public-Keygen(d) and same label.
The function returns a boolean value of "TRUE" if the signature is valid,
@@ -404,7 +405,7 @@ zid := GNSCrockfordDecode(zkl)
For example, assuming a zkl of 130 characters, the encoding would be:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
-zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
+zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
]]></artwork>
</section>
<section anchor="revocation" numbered="true" toc="default">
@@ -494,8 +495,7 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
<dt>ZONE KEY</dt>
<dd>
is the 256-bit public key zk of the zone which is being revoked.
- The wire format of this value is defined in <xref target="RFC8032" />,
- Section 5.1.5.
+ The wire format of this value is defined by the ZONE TYPE.
</dd>
</dl>
<t>
@@ -567,7 +567,7 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
</dd>
<dt>TTL</dt>
<dd>
- denotes the relative 64-bit time to live of of the record in
+ 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. The verifier may discard revocation if the TTL
indicates that it is already expired. However, the actual TTL of the
@@ -645,17 +645,17 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
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>
+ POW values D' MUST be greater than and not equal to 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>
+ <li>The current time MUST be between TIMESTAMP and
+ TIMESTAMP+TTL.</li>
</ol>
</section>
@@ -803,7 +803,7 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
delegate to.
A PKEY record MUST be the only record under a label. No other
records are allowed. The PKEY DATA entry wire format can be found
- found in <xref target="figure_pkeyrecord"/>.
+ in <xref target="figure_pkeyrecord"/>.
</t>
<figure anchor="figure_pkeyrecord">
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -857,7 +857,7 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
</dd>
<dt>L</dt>
<dd>
- is the prime-order subgroup of edwards25519 in <xref target="RFC7748" />.
+ is the order of the prime-order subgroup of edwards25519 in <xref target="RFC7748" />.
</dd>
</dl>
<t>
@@ -873,7 +873,7 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
zk := d * G
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
-d' := h * d mod L
+d' := (h * d) mod L
]]></artwork>
<t>
Equally, given a label, the output zk' of the ZKDF-Public(zk,label) function is
@@ -882,7 +882,7 @@ d' := h * d mod L
<artwork name="" type="" align="left" alt=""><![CDATA[
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
-zk' := h mod L * zk
+zk' := (h mod L) * zk
]]></artwork>
<t>
The PKEY cryptosystem uses a hash-based key derivation function (HKDF) as defined in
@@ -909,8 +909,8 @@ zk' := h mod L * zk
as defined in <xref target="MODES" /> (CTR-AES-256):
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
-DATA := CTR-AES256(K, IV, CIPHERTEXT)
CIPHERTEXT := CTR-AES256(K, IV, DATA)
+DATA := CTR-AES256(K, IV, CIPHERTEXT)
]]></artwork>
<t>
The key K and counter IV are derived from
@@ -1028,7 +1028,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
</dd>
<dt>L</dt>
<dd>
- is the prime-order subgroup of edwards25519 in <xref target="RFC7748" />.
+ is the order of the prime-order subgroup of edwards25519 in <xref target="RFC7748" />.
</dd>
</dl>
<t>
@@ -1047,7 +1047,7 @@ PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
h[31] &= 7
a1 := a / 8 /* 8 is the cofactor of Curve25519 */
-a2 := h * a1 mod L
+a2 := (h * a1) mod L
a' = a2 * 8 /* 8 is the cofactor of Curve25519 */
]]></artwork>
<t>
@@ -1121,13 +1121,13 @@ S * G == R + SHA512(R, zk', M) * zk'
(XSalsa20-Poly1305):
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
-DATA := XSalsa20(K, IV, CIPHERTEXT)
-CIPHERTEXT := XSalsa20(K, IV, DATA) = CIPHERTEXT | TAG
+CIPHERTEXT := XSalsa20-Poly1305(K, IV, DATA)
+DATA := XSalsa20-Poly1305(K, IV, CIPHERTEXT)
]]></artwork>
<t>
- The result of the XSalsa20 encryption function is the encrypted
+ The result of the XSalsa20-Poly1305 encryption function is the encrypted
ciphertext concatenated with the 128-bit authentication
- tag TAG.
+ tag.
Accordingly, the length of encrypted data equals the length of the
data plus the 16 bytes of the authentication tag.
</t>
@@ -1363,8 +1363,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
The GNUnet Tunnel Service record is used by
applications to establish a tunnel between two peers in the
peer-to-peer network (see <xref target="GNUnet"/>).
- In order to facilitate the use of such tunnels, the
- The GTS record serves as an example to how resolvers may automatically
+ The GTS record serves as an example of how resolvers may automatically
initiate tunnel establishment and provide IP address information in the
resolution process as specified in <xref target="resolution"/>.
</t>
@@ -1631,7 +1630,8 @@ q := SHA512 (HDKD-Public(zk, label))
<t>
Names in GNS are resolved by recursively querying the record storage.
Recursive in this context means that a resolver does not provide
- iterative results for a query (as is the case with iterative DNS resolution).
+ iterative results for a query.
+ <!--(as is the case with iterative DNS resolution). REMOVED -->
Instead, it MUST respond to a resolution request with either the
requested resource record or an error message in case the resolution
fails.
@@ -1641,7 +1641,7 @@ q := SHA512 (HDKD-Public(zk, label))
<t>
GNS resolution of a name must start in a given starting zone indicated using
a zone key.
- Details on how the starting zone may be determined is discussed in
+ Details on how the starting zone may be determined are discussed in
<xref target="governance" />.
</t>
<t>
@@ -1862,7 +1862,7 @@ example.com = zk2
to the remainder of the name to be resolved, and
resolved by querying the DNS name server(s). As the DNS servers
specified are possibly authoritative DNS servers, the GNS resolver MUST
- support recursive resolution and MUST NOT delegate this to the
+ 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.
@@ -1961,9 +1961,9 @@ NICK: eve
<t>
In this example, the returned NICK record is non-supplemental.
For the client, this means that the NICK belongs to the zone
- "alice.doe" and is published under the empty label along with an A
+ "alice.example" and is published under the empty label along with an A
record. The NICK record should be interpreted as: The zone defined by
- "alice.doe" wants to be referred to as "eve".
+ "alice.example" wants to be referred to as "eve".
In contrast, consider the following:
</t>
<artwork name="" type="" align="left" alt=""><