commit 920d7863d7ab5222f0ca0c0ad94fe75d5aa8d270
parent b3eea2102299e1718c7bb66aec49324fc14cb019
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Tue, 1 Feb 2022 16:43:46 +0100
Merge branch 'master' of ssh://git.gnunet.org/lsd0001
Diffstat:
1 file changed, 54 insertions(+), 38 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -199,9 +199,10 @@
</dd>
<dt>Top-Level Domain</dt>
<dd>
- The rightmost label in a GNS name is a GNS Top-Level Domain (TLD).
+ The rightmost part of a GNS name is a GNS Top-Level Domain (TLD).
+ A GNS TLD may consist of one or more labels.
Unlike DNS Top-Level Domains (defined in <xref target="RFC8499"/>),
- GNS does not expect all users to use the same global root zone. Instead,
+ GNS does not expect all users to use the same global root zone. Instead,
with the exception of Zone Top-Level Domains (see below),
GNS TLDs are typically part of the configuration of the local resolver
(see <xref target="governance"/>), and may thus not be globally unique.
@@ -235,12 +236,12 @@
</dd>
<dt>Zone Top-Level Domain</dt>
<dd>
- A GNS Zone Top-Level Domain (zTLD) is a GNS label used as the
- rightmost label in a GNS name which encodes a zone type and
+ A GNS Zone Top-Level Domain (zTLD) is a sequence of GNS labels at
+ the end of a GNS name which encodes a zone type and
zone key of a zone.
Due to the statistical uniqueness of zone keys, zTLDs are also globally unique.
- A zTLD label can only be distinguished from ordinary TLD labels
- by attempting to decode the label to a zone type and zone key.
+ A zTLD label sequence can only be distinguished from ordinary TLD label sequences
+ by attempting to decode the labels into a zone type and zone key.
</dd>
<dt>Resource Record</dt>
<dd>
@@ -390,7 +391,7 @@
<dt>Verify(zk,message,signature) -> boolean, Verify(zk',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
+ the private key d (or derived key d') corresponding to
the zone key zk (or derived zone key zk')
where d,zk := Keygen(). If deriviations were used, they
must have used the same label.
@@ -484,7 +485,8 @@ ztype|zkey := GNSCrockfordDecode(zkl)
Here, the most significant bytes of the "ztype|zkey" concatenation must be contained
in the rightmost label of the resulting string and the least significant
bytes in the leftmost label of the resulting string. This allows the
- resolver to determine the zone type and zkl length from the rightmost label.
+ resolver to determine the ztype and zkl length from the rightmost label and
+ to subsequently determine how many labels the zTLD should span.
For example, assuming a zkl of 130 characters, the encoding would be:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -500,15 +502,15 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
resolution MUST fail with an empty result set.
</t>
<t>
- In order to revoke a zone key, a signed revocation object MUST be
+ In order to revoke a zone key, a signed revocation message MUST be
published.
- This object MUST be signed using the private key.
- The revocation object is broadcast to the network.
+ This message MUST be signed using the private key.
+ The revocation message is broadcast to the network.
The specification of the broadcast mechanism is out of scope of this
document.
A possible broadcast mechanism for efficient flooding in a distributed
network is implemented in <xref target="GNUnet"/>.
- Alternatively, revocation objects could also be distributed via a
+ Alternatively, revocation messages could also be distributed via a
distributed ledger or a trusted central server.
To prevent
flooding attacks, the revocation message MUST contain a proof of work
@@ -541,8 +543,8 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
<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.
+ <xref target="figure_revocation"/> illustrates the format
+ of the data "P" on which the PoW is calculated.
</t>
<figure anchor="figure_revocation">
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -559,11 +561,11 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
- <t>The Wire Format of the PoW Message String.</t>
+ <t>The Format of the PoW Data.</t>
<dl>
<dt>POW</dt>
<dd>
- A 64-bit solution to the PoW. In network byte order.
+ A 64-bit value that is a solution to the PoW. In network byte order.
</dd>
<dt>TIMESTAMP</dt>
<dd>
@@ -582,7 +584,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
</dd>
</dl>
<t>
- Traditionally, PoW schemes require to find a POW such that
+ Traditionally, PoW schemes require to find a POW value 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
@@ -605,12 +607,12 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
<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>
+ <dd>The minimum average 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
+ The revocation message wire format is illustrated in
<xref target="figure_revocationdata"/>.
</t>
<figure anchor="figure_revocationdata">
@@ -652,8 +654,9 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
<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. The verifier may discard revocation if the TTL
- indicates that it is already expired. However, the actual TTL of the
+ 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 zeros in the
proof of work calculation.
</dd>
@@ -721,22 +724,27 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
The 32-bit zone type corresponding to the zone key.
</dd>
<dt>ZONE KEY / TIMESTAMP</dt>
- <dd>Both values as defined in the revocation data object above.</dd>
+ <dd>Both values as defined in the revocation message above.</dd>
</dl>
<t>
In order to verify a revocation the following steps must be taken,
- in order:
+ in order: <!-- FIXME: why can an implementation not change the order, say if one check is slower than other checks? -->
</t>
<ol>
<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 and not equal to D.</li>
+ <li>The average number of leading zeroes D' resulting from the provided
+ POW values MUST be greater than and not equal to D. Implementors
+ MUST NOT use an integer data type to calculate or represent 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>
+ <!-- FIXME: what if the TTL in the message disagrees with our calculations? What should be done?
+ What if floating point rounding errors cause a disagreement in TTL calculations?
+ IMO we should simply mandate that when FORWARDING a message, the sender should
+ use the TTL they calculated themselves. -->
<li>The current time MUST be between TIMESTAMP and
TIMESTAMP+TTL.</li>
</ol>
@@ -918,11 +926,11 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
<dl>
<dt>d</dt>
<dd>
- is a 256-bit ECDSA private key.
+ is a 256-bit ECDSA private key.
</dd>
<dt>zk</dt>
<dd>
- is the ECDSA public zone key corresponding to d.
+ is the ECDSA public zone key corresponding to d.
</dd>
<dt>p</dt>
<dd>
@@ -941,7 +949,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
<dt>KeyGen()</dt>
<dd>The generation of the private
scalar d and the curve point zk := d*G (where G is the group generator
- of the elliptic curve) as defined in Section 2.2. of
+ of the elliptic curve) as defined in Section 2.2. of
<xref target="RFC6979" /> represents the KeyGen() function.
</dd>
</dl>
@@ -1023,7 +1031,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
The block counter is a 32-bit integer value in network byte order.
The initialization vector is the expiration time of the
resource record block in network byte order.
- The resulting counter (IV) wire format can be found in
+ The resulting counter (IV) wire format can be found in
<xref target="figure_hkdf_ivs_pkey"/>.
</t>
<figure anchor="figure_hkdf_ivs_pkey">
@@ -1083,7 +1091,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
<dl>
<dt>d</dt>
<dd>
- is a 256-bit EdDSA private key.
+ is a 256-bit EdDSA private key.
</dd>
<dt>a</dt>
<dd>
@@ -1092,7 +1100,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
</dd>
<dt>zk</dt>
<dd>
- is the EdDSA public key corresponding to d. It is defined
+ is the EdDSA public key corresponding to d. It is defined
as the curve point a*G where G is the
group generator of the elliptic curve
as defined in <xref target="ed25519" />.
@@ -1116,7 +1124,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
The generation of the private key d and the associated public
key zk := a*G where G is the
group generator of the elliptic curve and a is an integer
- derived from d using the SHA-512 hash function
+ derived from d using the SHA-512 hash function
as defined
in Section 3.2. of <xref target="RFC8032" /> represents the KeyGen()
function.
@@ -1170,7 +1178,7 @@ zk' := h * zk
a concatenation of the label and the string "gns".
The result of the HKDF must be clamped and interpreted in network
byte order.
- a is the 256-bit integer corresponding to the 256-bit private
+ a is the 256-bit integer corresponding to the 256-bit private
key d.
The label is a UTF-8 string under which the resource records are
published.
@@ -1246,7 +1254,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
The nonce is combined with an 8 byte initialization vector.
The initialization vector is the expiration time of the
resource record block in network byte order.
- The resulting counter (IV) wire format is illustrated in
+ The resulting counter (IV) wire format is illustrated in
<xref target="figure_hkdf_ivs_edkey"/>.
</t>
<figure anchor="figure_hkdf_ivs_edkey">
@@ -1459,7 +1467,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
resolution process as specified in <xref target="resolution"/>.
</t>
<t>
- A GTS DATA entry wire format is illustrated in
+ A GTS DATA entry wire format is illustrated in
<xref target="figure_vpnrecord"/>.
</t>
<figure anchor="figure_vpnrecord">
@@ -1573,7 +1581,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
A GNS implementation must publish RRBLOCKs
in accordance to the properties and recommendations of the underlying
storage. This may include a periodic refresh publication.
- The GNS RRBLOCK wire format is illustrated in
+ The GNS RRBLOCK wire format is illustrated in
<xref target="figure_record_block"/>.
</t>
<figure anchor="figure_record_block">
@@ -1660,7 +1668,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
<t>
A symmetric encryption scheme is used to encrypt the resource records
set RDATA into the BDATA field of a GNS RRBLOCK.
- The wire format of the RDATA is illustrated in
+ The wire format of the RDATA is illustrated in
<xref target="figure_rdata"/>.
</t>
<figure anchor="figure_rdata">
@@ -2366,7 +2374,7 @@ NICK: john (Supplemental)
as a descriptive comment as defined above.
</t>
<t>
- GANA is requested to populate this registry as listed in
+ GANA is requested to populate this registry as listed in
<xref target="figure_rrtypenums"/>.
</t>
<figure anchor="figure_rrtypenums">
@@ -2786,6 +2794,14 @@ b9ae0482cdaa9095
]]>
</artwork>
</section>
+ <section pn="section-acks">
+ <name>Acknowledgements</name>
+ <t>
+ The authors thank D. J. Bernstein, A. Farrel and S. Bortzmeyer for their
+ insightful reviews. We thank NLnet and NGI DISCOVERY for funding
+ work on the GNU Name System.
+ </t>
+ </section>
</middle>
<back>
<references>
