commit 4cdd0509dcdaa039a982c31ec81f192bea3377f4
parent ca5614d7f6b1213c94dade53a251511da5a00985
Author: Martin Schanzenbach <mschanzenbach@posteo.de>
Date: Sat, 15 Feb 2020 19:31:21 +0100
attempt clarify supplemental
Diffstat:
3 files changed, 223 insertions(+), 68 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
@@ -1215,6 +1215,9 @@ table {
<li class="toc ulEmpty" id="section-toc.1-1.6.2.2.2.5">
<p id="section-toc.1-1.6.2.2.2.5.1"><a href="#section-6.2.5" class="xref">6.2.5</a>. <a href="#name-vpn-2" class="xref">VPN</a><a href="#section-toc.1-1.6.2.2.2.5.1" class="pilcrow">¶</a></p>
</li>
+<li class="toc ulEmpty" id="section-toc.1-1.6.2.2.2.6">
+ <p id="section-toc.1-1.6.2.2.2.6.1"><a href="#section-6.2.6" class="xref">6.2.6</a>. <a href="#name-supplemental-records" class="xref">Supplemental Records</a><a href="#section-toc.1-1.6.2.2.2.6.1" class="pilcrow">¶</a></p>
+</li>
</ul>
</li>
</ul>
@@ -2317,6 +2320,55 @@ table {
does not support setting up a tunnnel.<a href="#section-6.2.5-1" class="pilcrow">¶</a></p>
</section>
</div>
+<div id="suppl_processing">
+<section id="section-6.2.6">
+ <h4 id="name-supplemental-records">
+<a href="#section-6.2.6" class="section-number selfRef">6.2.6. </a><a href="#name-supplemental-records" class="section-name selfRef">Supplemental Records</a>
+ </h4>
+<p id="section-6.2.6-1">
+ Supplemental records are only relevant to the recursive resolver
+ if the record set in question is the final result which is to
+ be returned to the client. The resolver only returns a record set
+ including the supplemental records if one of the non-supplemental
+ records matches the queried record type.
+ Supplemental records MUST NOT be published and resolved under the
+ empty label. If a resolver encounters a supplemental under the
+ empty label, it MUST discard the record.<a href="#section-6.2.6-1" class="pilcrow">¶</a></p>
+<p id="section-6.2.6-2">
+ The differentiation between a supplemental and non-supplemental
+ record allows the client to match the record to the authoritative
+ zone. Consider the following example:<a href="#section-6.2.6-2" class="pilcrow">¶</a></p>
+<figure id="figure-14">
+ <div class="artwork art-text alignLeft" id="section-6.2.6-3.1">
+<pre>
+ Query: alice.bob (type=A)
+ Result:
+ A: 1.2.3.4
+ NICK: Alice
+ </pre>
+</div>
+<figcaption><a href="#figure-14" class="selfRef">Figure 14</a></figcaption></figure>
+<p id="section-6.2.6-4">
+ In this example, the returned NICK record is non-supplemental.
+ For the client, this means that the NICK belongs to the zone
+ "alice.bob" and is published under the empty label along with an A
+ record. In contrast, if the resolution yields the following:<a href="#section-6.2.6-4" class="pilcrow">¶</a></p>
+<figure id="figure-15">
+ <div class="artwork art-text alignLeft" id="section-6.2.6-5.1">
+<pre>
+ Query: alice.bob (type=A)
+ Result:
+ A: 1.2.3.4
+ NICK: Bob (Supplemental)
+ </pre>
+</div>
+<figcaption><a href="#figure-15" class="selfRef">Figure 15</a></figcaption></figure>
+<p id="section-6.2.6-6">
+ In this case, the NICK record is marked as supplemental. This means that
+ the NICK record belongs to the zone "bob" and is published under the
+ label "alice" along with an A record.<a href="#section-6.2.6-6" class="pilcrow">¶</a></p>
+</section>
+</div>
</section>
</div>
</section>
@@ -2343,7 +2395,7 @@ table {
The following the the basic data "REVDAT" on which the proof-of work is
calculated:<a href="#section-7-3" class="pilcrow">¶</a></p>
<div id="figure_revocation">
-<figure id="figure-14">
+<figure id="figure-16">
<div class="artwork art-text alignLeft" id="section-7-4.1">
<pre>
0 8 16 24 32 40 48 56
@@ -2357,11 +2409,11 @@ table {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-14" class="selfRef">Figure 14</a></figcaption></figure>
+<figcaption><a href="#figure-16" class="selfRef">Figure 16</a></figcaption></figure>
</div>
<p id="section-7-5">
A single pass in the proof-of-work algorithm is defined as follows:<a href="#section-7-5" class="pilcrow">¶</a></p>
-<figure id="figure-15">
+<figure id="figure-17">
<div class="artwork art-text alignLeft" id="section-7-6.1">
<pre>
DK := scrypt (P := REV)
@@ -2370,7 +2422,7 @@ table {
REVDATA := scrypt(P := enc)
</pre>
</div>
-<figcaption><a href="#figure-15" class="selfRef">Figure 15</a></figcaption></figure>
+<figcaption><a href="#figure-17" class="selfRef">Figure 17</a></figcaption></figure>
<p id="section-7-7">
where "scrypt" is the scrypt algorithm as defined in
<span>[<a href="#RFC7914" class="xref">RFC7914</a>]</span> with the following parameters set:<a href="#section-7-7" class="pilcrow">¶</a></p>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
@@ -83,12 +83,13 @@ Table of Contents
6.2.3. CNAME . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2.5. VPN . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 6.2.6. Supplemental Records . . . . . . . . . . . . . . . . 19
7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 19
8. Determining the Root Zone and Zone Governance . . . . . . . . 20
- 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
- 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
- 11. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 21
- 12. Normative References . . . . . . . . . . . . . . . . . . . . 23
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
+ 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
+ 11. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 12. Normative References . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
@@ -105,7 +106,6 @@ Table of Contents
DNS was not designed with security as a goal. This makes it very
vulnerable, especially to attackers that have the technical
capabilities of an entire nation state at their disposal. This
- specification describes a censorship-resistant, privacy-preserving
@@ -114,6 +114,7 @@ Schanzenbach, et al. Expires 13 May 2020 [Page 2]
Internet-Draft The GNU Name System November 2019
+ specification describes a censorship-resistant, privacy-preserving
and decentralized name system: The GNU Name System (GNS). It is
designed to provide a secure alternative to DNS, especially when
censorship or manipulation is encountered. GNS can bind names to any
@@ -164,7 +165,6 @@ Internet-Draft The GNU Name System November 2019
-
Schanzenbach, et al. Expires 13 May 2020 [Page 3]
Internet-Draft The GNU Name System November 2019
@@ -1010,6 +1010,44 @@ Schanzenbach, et al. Expires 13 May 2020 [Page 18]
Internet-Draft The GNU Name System November 2019
+6.2.6. Supplemental Records
+
+ Supplemental records are only relevant to the recursive resolver if
+ the record set in question is the final result which is to be
+ returned to the client. The resolver only returns a record set
+ including the supplemental records if one of the non-supplemental
+ records matches the queried record type. Supplemental records MUST
+ NOT be published and resolved under the empty label. If a resolver
+ encounters a supplemental under the empty label, it MUST discard the
+ record.
+
+ The differentiation between a supplemental and non-supplemental
+ record allows the client to match the record to the authoritative
+ zone. Consider the following example:
+
+ Query: alice.bob (type=A)
+ Result:
+ A: 1.2.3.4
+ NICK: Alice
+
+ Figure 14
+
+ In this example, the returned NICK record is non-supplemental. For
+ the client, this means that the NICK belongs to the zone "alice.bob"
+ and is published under the empty label along with an A record. In
+ contrast, if the resolution yields the following:
+
+ Query: alice.bob (type=A)
+ Result:
+ A: 1.2.3.4
+ NICK: Bob (Supplemental)
+
+ Figure 15
+
+ In this case, the NICK record is marked as supplemental. This means
+ that the NICK record belongs to the zone "bob" and is published under
+ the label "alice" along with an A record.
+
7. Zone Revocation
Whenever a recursive resolver encounters a new GNS zone, it MUST
@@ -1020,6 +1058,14 @@ Internet-Draft The GNU Name System November 2019
In order to revoke a zone key, a signed revocation object SHOULD be
published. This object MUST be signed using the private zone key.
The revocation object is flooded in the overlay network. To prevent
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 19]
+
+Internet-Draft The GNU Name System November 2019
+
+
flooding attacks, the revocation message MUST contain a proof-of-
work. The revocation message including the proof-of-work MAY be
calculated ahead of time to support timely revocation.
@@ -1037,7 +1083,7 @@ Internet-Draft The GNU Name System November 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 14
+ Figure 16
A single pass in the proof-of-work algorithm is defined as follows:
@@ -1046,7 +1092,7 @@ Internet-Draft The GNU Name System November 2019
EREV := AES (DK, IV, REV) /* TODO this is more complex */
REVDATA := scrypt(P := enc)
- Figure 15
+ Figure 17
where "scrypt" is the scrypt algorithm as defined in [RFC7914] with
the following parameters set:
@@ -1057,15 +1103,6 @@ Internet-Draft The GNU Name System November 2019
p := 2 /* Parallelization parameter */
dkLen := 512 /* Intended output length */
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 19]
-
-Internet-Draft The GNU Name System November 2019
-
-
The above function is called with different values for the "NONCE" in
"REVDAT" until the amount of leading zeroes is greater or equal 25.
@@ -1077,6 +1114,14 @@ Internet-Draft The GNU Name System November 2019
points to a local or remote start zone key. A resolver client may
also determine the start zone from the suffix of the name given for
resolution or using information retrieved out of band. The
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 20]
+
+Internet-Draft The GNU Name System November 2019
+
+
governance model of any zone is at the sole discretion of the zone
owner. However, the choice of start zone(s) is at the sole
discretion of the local system administrator or user.
@@ -1108,20 +1153,6 @@ Internet-Draft The GNU Name System November 2019
locally managed zone matches the suffix of the name to be resolved,
resolution SHOULD start from the respective local zone:
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 20]
-
-Internet-Draft The GNU Name System November 2019
-
-
Example name: www.example.gnu
Local zones:
fr = (d0,zk0)
@@ -1138,6 +1169,15 @@ Internet-Draft The GNU Name System November 2019
".". If multiple suffixes match the name to resolve, the longest
matching suffix MUST BE used. The suffix length of two results
cannot be equal, as this would indicate a misconfiguration. If both
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 21]
+
+Internet-Draft The GNU Name System November 2019
+
+
a locally managed zone and a configuration entry exist for the same
suffix, the locally managed zone MUST have priority.
@@ -1171,13 +1211,6 @@ Internet-Draft The GNU Name System November 2019
f89333903b284fe8
1878bf47f3b39da0
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 21]
-
-Internet-Draft The GNU Name System November 2019
-
-
zk (public zone key) :=
dff911496d025d7e
0885c03d19153e99
@@ -1194,6 +1227,13 @@ Internet-Draft The GNU Name System November 2019
6668e9f684f4dc33
6d656b27392b0fee
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 22]
+
+Internet-Draft The GNU Name System November 2019
+
+
d_h :=
01fb61f482c17633
77611c4c2509e0f3
@@ -1226,14 +1266,6 @@ Internet-Draft The GNU Name System November 2019
3425e8a811ae59d2
99e2747285d2a479
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 22]
-
-Internet-Draft The GNU Name System November 2019
-
-
TWOFISH_IV :=
071be189a9d236f9
b4a3654bb8c281d4
@@ -1250,6 +1282,14 @@ Internet-Draft The GNU Name System November 2019
00000000
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 23]
+
+Internet-Draft The GNU Name System November 2019
+
+
RRBLOCK :=
055cb070e05fe6de SIGNATURE
ad694a50e5b4dedd
@@ -1281,15 +1321,6 @@ Internet-Draft The GNU Name System November 2019
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 23]
-
-Internet-Draft The GNU Name System November 2019
-
-
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
@@ -1308,6 +1339,13 @@ Internet-Draft The GNU Name System November 2019
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 24]
+
+Internet-Draft The GNU Name System November 2019
+
+
[RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The
Advanced Encryption Standard (AES) Cipher Algorithm in the
SNMP User-based Security Model", RFC 3826,
@@ -1338,14 +1376,6 @@ Internet-Draft The GNU Name System November 2019
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <https://www.rfc-editor.org/info/rfc6979>.
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 24]
-
-Internet-Draft The GNU Name System November 2019
-
-
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
@@ -1364,6 +1394,14 @@ Internet-Draft The GNU Name System November 2019
Authors' Addresses
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 25]
+
+Internet-Draft The GNU Name System November 2019
+
+
Martin Schanzenbach
GNUnet e.V.
Boltzmannstrasse 3
@@ -1397,4 +1435,22 @@ Authors' Addresses
-Schanzenbach, et al. Expires 13 May 2020 [Page 25]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 26]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -1071,6 +1071,53 @@
does not support setting up a tunnnel.
</t>
</section>
+ <section anchor="suppl_processing" numbered="true" toc="default">
+ <name>Supplemental Records</name>
+ <t>
+ Supplemental records are only relevant to the recursive resolver
+ if the record set in question is the final result which is to
+ be returned to the client. The resolver only returns a record set
+ including the supplemental records if one of the non-supplemental
+ records matches the queried record type.
+ Supplemental records MUST NOT be published and resolved under the
+ empty label. If a resolver encounters a supplemental under the
+ empty label, it MUST discard the record.
+ </t>
+ <t>
+ The differentiation between a supplemental and non-supplemental
+ record allows the client to match the record to the authoritative
+ zone. Consider the following example:
+ </t>
+ <figure>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ Query: alice.bob (type=A)
+ Result:
+ A: 1.2.3.4
+ NICK: Alice
+ ]]></artwork>
+ </figure>
+ <t>
+ In this example, the returned NICK record is non-supplemental.
+ For the client, this means that the NICK belongs to the zone
+ "alice.bob" and is published under the empty label along with an A
+ record. In contrast, if the resolution yields the following:
+ </t>
+ <figure>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ Query: alice.bob (type=A)
+ Result:
+ A: 1.2.3.4
+ NICK: Bob (Supplemental)
+ ]]></artwork>
+ </figure>
+ <t>
+ In this case, the NICK record is marked as supplemental. This means that
+ the NICK record belongs to the zone "bob" and is published under the
+ label "alice" along with an A record.
+ </t>
+
+
+ </section>
</section>
</section>
<section anchor="revocation" numbered="true" toc="default">
