commit 690af736f61ab357647dd64fcb806232c16d1c75
parent bdfea14f7efe6c9f6a130461da085b1aed7a50f8
Author: Martin Schanzenbach <mschanzenbach@posteo.de>
Date: Sun, 16 Feb 2020 13:15:21 +0100
add comments CG; IANA
Diffstat:
3 files changed, 305 insertions(+), 204 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
@@ -1216,7 +1216,7 @@ table {
<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>
+ <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-nick-2" class="xref">NICK</a><a href="#section-toc.1-1.6.2.2.2.6.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
@@ -1466,27 +1466,11 @@ table {
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-record-types" class="section-name selfRef">Record Types</a>
</h3>
<p id="section-3.1-1">
- GNS-specific record type numbers start at 2^16, i.e. after the record
- type numbers for DNS. The following is a list of defined and reserved
- record types in GNS:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
-<div id="figure_rrtypenums">
-<figure id="figure-3">
- <div class="artwork art-text alignLeft" id="section-3.1-2.1">
-<pre>
- Number | Type | Comment
- ------------------------------------------------------------
- 65536 | PKEY | GNS delegation
- 65537 | NICK | GNS zone nickname
- 65538 | LEHO | Legacy hostname
- 65539 | VPN | Virtual private network
- 65540 | GNS2DNS | DNS delegation
- 65541 | BOX | Boxed record (for TLSA/SRV)
- 65542 up to 2^24 - 1 | - | Reserved
- 2^24 up to 2^32 - 1 | - | Unassigned / For private use
- </pre>
-</div>
-<figcaption><a href="#figure-3" class="selfRef">Figure 3</a></figcaption></figure>
-</div>
+ A registry of GNS Record Types is described in Section 10. The
+ registration policy for this registry is "First Come First Served", as
+ described in <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>. When requesting new entries, careful
+ consideration of the following criteria is strongly advised:
+ FIXME: ausdenken was wir da gerne haetten.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="gnsrecords_pkey">
@@ -1499,7 +1483,7 @@ table {
delegate to. A PKEY record MUST be the only record under a label. No other
records are allowed. A PKEY DATA entry has the following format:<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<div id="figure_pkeyrecord">
-<figure id="figure-4">
+<figure id="figure-3">
<div class="artwork art-text alignLeft" id="section-3.2-2.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1511,7 +1495,7 @@ table {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-4" class="selfRef">Figure 4</a></figcaption></figure>
+<figcaption><a href="#figure-3" class="selfRef">Figure 3</a></figcaption></figure>
</div>
<p id="section-3.2-3">
where:<a href="#section-3.2-3" class="pilcrow">¶</a></p>
@@ -1534,7 +1518,7 @@ table {
<span>[<a href="#RFC1034" class="xref">RFC1034</a>]</span> for DNS names.
A GNS2DNS DATA entry has the following format:<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<div id="figure_gns2dnsrecord">
-<figure id="figure-5">
+<figure id="figure-4">
<div class="artwork art-text alignLeft" id="section-3.3-2.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1551,7 +1535,7 @@ table {
+-----------------------------------------------+
</pre>
</div>
-<figcaption><a href="#figure-5" class="selfRef">Figure 5</a></figcaption></figure>
+<figcaption><a href="#figure-4" class="selfRef">Figure 4</a></figcaption></figure>
</div>
<p id="section-3.3-3">
where:<a href="#section-3.3-3" class="pilcrow">¶</a></p>
@@ -1584,7 +1568,7 @@ table {
resource record with an IPv4 or IPv6 address.
A LEHO DATA entry has the following format:<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<div id="figure_lehorecord">
-<figure id="figure-6">
+<figure id="figure-5">
<div class="artwork art-text alignLeft" id="section-3.4-2.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1596,7 +1580,7 @@ table {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-6" class="selfRef">Figure 6</a></figcaption></figure>
+<figcaption><a href="#figure-5" class="selfRef">Figure 5</a></figcaption></figure>
</div>
<p id="section-3.4-3">
where:<a href="#section-3.4-3" class="pilcrow">¶</a></p>
@@ -1621,13 +1605,15 @@ table {
Nickname records can be used by zone administrators to publish an
indication on what label this zone prefers to be referred to.
This is a suggestion to other zones what label to use when creating a
- PKEY <a href="#gnsrecords_pkey" class="xref">Section 3.2</a> record containing this zone's
+ PKEY (<a href="#gnsrecords_pkey" class="xref">Section 3.2</a>) record containing this zone's
public zone key.
This record SHOULD only be stored under the empty label "@" but MAY be
returned with record sets under any label as a supplemental record.
+ <a href="#nick_processing" class="xref">Section 6.2.6</a> details how a resolver must process
+ supplemental and non-supplemental NICK records.
A NICK DATA entry has the following format:<a href="#section-3.5-1" class="pilcrow">¶</a></p>
<div id="figure_nickrecord">
-<figure id="figure-7">
+<figure id="figure-6">
<div class="artwork art-text alignLeft" id="section-3.5-2.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1639,7 +1625,7 @@ table {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-7" class="selfRef">Figure 7</a></figcaption></figure>
+<figcaption><a href="#figure-6" class="selfRef">Figure 6</a></figcaption></figure>
</div>
<p id="section-3.5-3">
where:<a href="#section-3.5-3" class="pilcrow">¶</a></p>
@@ -1671,7 +1657,7 @@ table {
For reference, see also <span>[<a href="#RFC2782" class="xref">RFC2782</a>]</span>.
A BOX DATA entry has the following format:<a href="#section-3.6-1" class="pilcrow">¶</a></p>
<div id="figure_boxrecord">
-<figure id="figure-8">
+<figure id="figure-7">
<div class="artwork art-text alignLeft" id="section-3.6-2.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1685,7 +1671,7 @@ table {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-8" class="selfRef">Figure 8</a></figcaption></figure>
+<figcaption><a href="#figure-7" class="selfRef">Figure 7</a></figcaption></figure>
</div>
<p id="section-3.6-3">
where:<a href="#section-3.6-3" class="pilcrow">¶</a></p>
@@ -1719,7 +1705,7 @@ table {
<p id="section-3.7-1">
A VPN DATA entry has the following format:<a href="#section-3.7-1" class="pilcrow">¶</a></p>
<div id="figure_vpnrecord">
-<figure id="figure-9">
+<figure id="figure-8">
<div class="artwork art-text alignLeft" id="section-3.7-2.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1737,7 +1723,7 @@ table {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-9" class="selfRef">Figure 9</a></figcaption></figure>
+<figcaption><a href="#figure-8" class="selfRef">Figure 8</a></figcaption></figure>
</div>
<p id="section-3.7-3">
where:<a href="#section-3.7-3" class="pilcrow">¶</a></p>
@@ -1859,7 +1845,7 @@ table {
DHT. This may include a periodic refresh publication.
A GNS RRBLOCK has the following format:<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<div id="figure_record_block">
-<figure id="figure-10">
+<figure id="figure-9">
<div class="artwork art-text alignLeft" id="section-4.2-2.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1888,7 +1874,7 @@ table {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-10" class="selfRef">Figure 10</a></figcaption></figure>
+<figcaption><a href="#figure-9" class="selfRef">Figure 9</a></figcaption></figure>
</div>
<p id="section-4.2-3">where:<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-4.2-4">
@@ -1952,7 +1938,7 @@ table {
set RDATA into the BDATA field of a GNS RRBLOCK.
The wire format of the RDATA looks as follows:<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<div id="figure_rdata">
-<figure id="figure-11">
+<figure id="figure-10">
<div class="artwork art-text alignLeft" id="section-4.3-2.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1980,7 +1966,7 @@ table {
/ /
</pre>
</div>
-<figcaption><a href="#figure-11" class="selfRef">Figure 11</a></figcaption></figure>
+<figcaption><a href="#figure-10" class="selfRef">Figure 10</a></figcaption></figure>
</div>
<p id="section-4.3-3">where:<a href="#section-4.3-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-4.3-4">
@@ -2030,7 +2016,7 @@ table {
<span>[<a href="#RFC3826" class="xref">RFC3826</a>]</span> key
and a 256-bit TWOFISH <span>[<a href="#TWOFISH" class="xref">TWOFISH</a>]</span> key:<a href="#section-4.3-7" class="pilcrow">¶</a></p>
<div id="figure_hkdf_keys">
-<figure id="figure-12">
+<figure id="figure-11">
<div class="artwork art-text alignLeft" id="section-4.3-8.1">
<pre>
0 8 16 24 32 40 48 56
@@ -2047,13 +2033,13 @@ table {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-12" class="selfRef">Figure 12</a></figcaption></figure>
+<figcaption><a href="#figure-11" class="selfRef">Figure 11</a></figcaption></figure>
</div>
<p id="section-4.3-9">
Similarly, we divide "IV" into a 128-bit initialization vector
and a 128-bit initialization vector:<a href="#section-4.3-9" class="pilcrow">¶</a></p>
<div id="figure_hkdf_ivs">
-<figure id="figure-13">
+<figure id="figure-12">
<div class="artwork art-text alignLeft" id="section-4.3-10.1">
<pre>
0 8 16 24 32 40 48 56
@@ -2066,7 +2052,7 @@ table {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-13" class="selfRef">Figure 13</a></figcaption></figure>
+<figcaption><a href="#figure-12" class="selfRef">Figure 12</a></figcaption></figure>
</div>
<p id="section-4.3-11">
The keys and IVs are used for a CFB128-AES-256 and
@@ -2320,25 +2306,25 @@ 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">
+<div id="nick_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 id="name-nick-2">
+<a href="#section-6.2.6" class="section-number selfRef">6.2.6. </a><a href="#name-nick-2" class="section-name selfRef">NICK</a>
</h4>
<p id="section-6.2.6-1">
- Supplemental records are only relevant to the recursive resolver
+ NIICK 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>
+ be returned to the client. The encountered NICK records may either
+ be supplemental (see <a href="#rrecords" class="xref">Section 3</a>) or
+ non-supplemental.
+ If the NICK record is supplemental, the resolver only returns the
+ record set if one of the non-supplemental records matches the
+ queried record type.<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">
+ NICK 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-13">
<div class="artwork art-text alignLeft" id="section-6.2.6-3.1">
<pre>
Query: alice.doe (type=A)
@@ -2347,7 +2333,7 @@ table {
NICK: eve
</pre>
</div>
-<figcaption><a href="#figure-14" class="selfRef">Figure 14</a></figcaption></figure>
+<figcaption><a href="#figure-13" class="selfRef">Figure 13</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
@@ -2355,7 +2341,7 @@ table {
record. The NICK record should be interpreted as: The zone defined by
"alice.doe" wants to be referred to as "eve".
In contrast, consider the following:<a href="#section-6.2.6-4" class="pilcrow">¶</a></p>
-<figure id="figure-15">
+<figure id="figure-14">
<div class="artwork art-text alignLeft" id="section-6.2.6-5.1">
<pre>
Query: alice.doe (type=A)
@@ -2364,7 +2350,7 @@ table {
NICK: john (Supplemental)
</pre>
</div>
-<figcaption><a href="#figure-15" class="selfRef">Figure 15</a></figcaption></figure>
+<figcaption><a href="#figure-14" class="selfRef">Figure 14</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 "doe" and is published under the
@@ -2400,7 +2386,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-16">
+<figure id="figure-15">
<div class="artwork art-text alignLeft" id="section-7-4.1">
<pre>
0 8 16 24 32 40 48 56
@@ -2414,11 +2400,11 @@ table {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-16" class="selfRef">Figure 16</a></figcaption></figure>
+<figcaption><a href="#figure-15" class="selfRef">Figure 15</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-17">
+<figure id="figure-16">
<div class="artwork art-text alignLeft" id="section-7-6.1">
<pre>
DK := scrypt (P := REV)
@@ -2427,7 +2413,7 @@ table {
REVDATA := scrypt(P := enc)
</pre>
</div>
-<figcaption><a href="#figure-17" class="selfRef">Figure 17</a></figcaption></figure>
+<figcaption><a href="#figure-16" class="selfRef">Figure 16</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>
@@ -2545,7 +2531,42 @@ table {
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
</h2>
<p id="section-10-1">
- This will be fun<a href="#section-10-1" class="pilcrow">¶</a></p>
+ IANA is requested to create an "GNU Name System Record Type" registry.
+The registry shall record for each entry:<a href="#section-10-1" class="pilcrow">¶</a></p>
+<ul>
+<li id="section-10-2.1">Type: The name of the record type (case insensitive ASCII
+ string, restricted to alphanumeric characters<a href="#section-10-2.1" class="pilcrow">¶</a>
+</li>
+<li id="section-10-2.2">Number: 32-bit, above 65535<a href="#section-10-2.2" class="pilcrow">¶</a>
+</li>
+<li id="section-10-2.3">Contact: The contact information of a person to contact for
+ further information<a href="#section-10-2.3" class="pilcrow">¶</a>
+</li>
+<li id="section-10-2.4">References: Optionally, references describing the record type
+ (such as an RFC)<a href="#section-10-2.4" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-10-3">
+ The registration policy for this sub-registry is "First Come First
+ Served", as described in <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.
+ IANA is requested to populate this registry as follows:<a href="#section-10-3" class="pilcrow">¶</a></p>
+<div id="figure_rrtypenums">
+<figure id="figure-17">
+ <div class="artwork art-text alignLeft" id="section-10-4.1">
+<pre>
+ Number | Type | Contact | References
+ ---------+-----------------+---------+---------
+ 65536 | PKEY | N/A | [This.I-D]
+ 65537 | NICK | N/A | [This.I-D]
+ 65538 | LEHO | N/A | [This.I-D]
+ 65539 | VPN | N/A | [This.I-D]
+ 65540 | GNS2DNS | N/A | [This.I-D]
+ 65541 | BOX | N/A | [This.I-D]
+ FIXME We have a lot more?
+ </pre>
+</div>
+<figcaption><a href="#figure-17" class="selfRef">Figure 17</a></figcaption></figure>
+</div>
</section>
</div>
<section id="section-11">
@@ -2700,6 +2721,9 @@ table {
<dt id="RFC8032">[RFC8032]</dt>
<dd>
<span class="refAuthor">Josefsson, S.</span><span class="refAuthor"> and I. Liusvaara</span>, <span class="refTitle">"Edwards-Curve Digital Signature Algorithm (EdDSA)"</span>, <span class="seriesInfo">RFC 8032</span>, <span class="seriesInfo">DOI 10.17487/RFC8032</span>, <time datetime="2017-01">January 2017</time>, <span><<a href="https://www.rfc-editor.org/info/rfc8032">https://www.rfc-editor.org/info/rfc8032</a>></span>. </dd>
+<dt id="RFC8126">[RFC8126]</dt>
+<dd>
+<span class="refAuthor">Cotton, M.</span><span class="refAuthor">, Leiba, B.</span><span class="refAuthor">, and T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06">June 2017</time>, <span><<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>></span>. </dd>
<dt id="TWOFISH">[TWOFISH]</dt>
<dd>
<span class="refAuthor">Schneier, B.</span>, <span class="refTitle">"The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition"</span>, <time datetime="1999-03">March 1999</time>. </dd>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
@@ -83,13 +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 . . . . . . . . . . . . . . . . . . . . . . . 20
+ 6.2.6. NICK . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 19
8. Determining the Root Zone and Zone Governance . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
- 11. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 22
- 12. Normative References . . . . . . . . . . . . . . . . . . . . 24
+ 11. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 12. Normative References . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction
@@ -284,22 +284,11 @@ Internet-Draft The GNU Name System November 2019
3.1. Record Types
- GNS-specific record type numbers start at 2^16, i.e. after the record
- type numbers for DNS. The following is a list of defined and
- reserved record types in GNS:
-
- Number | Type | Comment
- ------------------------------------------------------------
- 65536 | PKEY | GNS delegation
- 65537 | NICK | GNS zone nickname
- 65538 | LEHO | Legacy hostname
- 65539 | VPN | Virtual private network
- 65540 | GNS2DNS | DNS delegation
- 65541 | BOX | Boxed record (for TLSA/SRV)
- 65542 up to 2^24 - 1 | - | Reserved
- 2^24 up to 2^32 - 1 | - | Unassigned / For private use
-
- Figure 3
+ A registry of GNS Record Types is described in Section 10. The
+ registration policy for this registry is "First Come First Served",
+ as described in [RFC8126]. When requesting new entries, careful
+ consideration of the following criteria is strongly advised: FIXME:
+ ausdenken was wir da gerne haetten.
3.2. PKEY
@@ -317,7 +306,7 @@ Internet-Draft The GNU Name System November 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 4
+ Figure 3
where:
@@ -333,6 +322,17 @@ Internet-Draft The GNU Name System November 2019
+
+
+
+
+
+
+
+
+
+
+
Schanzenbach, et al. Expires 13 May 2020 [Page 6]
Internet-Draft The GNU Name System November 2019
@@ -351,7 +351,7 @@ Internet-Draft The GNU Name System November 2019
| |
+-----------------------------------------------+
- Figure 5
+ Figure 4
where:
@@ -379,7 +379,7 @@ Internet-Draft The GNU Name System November 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 6
+ Figure 5
where:
@@ -403,10 +403,12 @@ Internet-Draft The GNU Name System November 2019
Nickname records can be used by zone administrators to publish an
indication on what label this zone prefers to be referred to. This
is a suggestion to other zones what label to use when creating a PKEY
- Section 3.2 record containing this zone's public zone key. This
+ (Section 3.2) record containing this zone's public zone key. This
record SHOULD only be stored under the empty label "@" but MAY be
returned with record sets under any label as a supplemental record.
- A NICK DATA entry has the following format:
+ Section 6.2.6 details how a resolver must process supplemental and
+ non-supplemental NICK records. A NICK DATA entry has the following
+ format:
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -416,7 +418,7 @@ Internet-Draft The GNU Name System November 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 7
+ Figure 6
where:
@@ -443,8 +445,6 @@ Internet-Draft The GNU Name System November 2019
-
-
Schanzenbach, et al. Expires 13 May 2020 [Page 8]
Internet-Draft The GNU Name System November 2019
@@ -460,7 +460,7 @@ Internet-Draft The GNU Name System November 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 8
+ Figure 7
where:
@@ -494,7 +494,7 @@ Internet-Draft The GNU Name System November 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 9
+ Figure 8
where:
@@ -643,7 +643,7 @@ Internet-Draft The GNU Name System November 2019
/ |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 10
+ Figure 9
where:
@@ -718,7 +718,7 @@ Internet-Draft The GNU Name System November 2019
/ PADDING /
/ /
- Figure 11
+ Figure 10
where:
@@ -775,7 +775,7 @@ Internet-Draft The GNU Name System November 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 12
+ Figure 11
@@ -798,7 +798,7 @@ Internet-Draft The GNU Name System November 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 13
+ Figure 12
The keys and IVs are used for a CFB128-AES-256 and CFB128-TWOFISH-256
chained symmetric cipher. Both ciphers are used in Cipher FeedBack
@@ -1010,18 +1010,16 @@ Schanzenbach, et al. Expires 13 May 2020 [Page 18]
Internet-Draft The GNU Name System November 2019
-6.2.6. Supplemental Records
+6.2.6. NICK
- 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.
+ NIICK 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 encountered NICK records may either be supplemental
+ (see Section 3) or non-supplemental. If the NICK record is
+ supplemental, the resolver only returns the record set if one of the
+ non-supplemental records matches the queried record type.
- The differentiation between a supplemental and non-supplemental
+ The differentiation between a supplemental and non-supplemental NICK
record allows the client to match the record to the authoritative
zone. Consider the following example:
@@ -1030,7 +1028,7 @@ Internet-Draft The GNU Name System November 2019
A: 1.2.3.4
NICK: eve
- Figure 14
+ Figure 13
In this example, the returned NICK record is non-supplemental. For
the client, this means that the NICK belongs to the zone "alice.doe"
@@ -1044,7 +1042,7 @@ Internet-Draft The GNU Name System November 2019
A: 1.2.3.4
NICK: john (Supplemental)
- Figure 15
+ Figure 14
In this case, the NICK record is marked as supplemental. This means
that the NICK record belongs to the zone "doe" and is published under
@@ -1053,10 +1051,12 @@ Internet-Draft The GNU Name System November 2019
"john". This distinction is likely useful for other records
published as supplemental.
+7. Zone Revocation
-
-
-
+ 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.
@@ -1066,13 +1066,6 @@ Schanzenbach, et al. Expires 13 May 2020 [Page 19]
Internet-Draft The GNU Name System November 2019
-7. Zone Revocation
-
- 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.
-
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
@@ -1093,7 +1086,7 @@ Internet-Draft The GNU Name System November 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 16
+ Figure 15
A single pass in the proof-of-work algorithm is defined as follows:
@@ -1102,7 +1095,7 @@ Internet-Draft The GNU Name System November 2019
EREV := AES (DK, IV, REV) /* TODO this is more complex */
REVDATA := scrypt(P := enc)
- Figure 17
+ Figure 16
where "scrypt" is the scrypt algorithm as defined in [RFC7914] with
the following parameters set:
@@ -1113,6 +1106,13 @@ Internet-Draft The GNU Name System November 2019
p := 2 /* Parallelization parameter */
dkLen := 512 /* Intended output length */
+ The above function is called with different values for the "NONCE" in
+ "REVDAT" until the amount of leading zeroes is greater or equal 25.
+
+
+
+
+
@@ -1122,9 +1122,6 @@ Schanzenbach, et al. Expires 13 May 2020 [Page 20]
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.
-
8. Determining the Root Zone and Zone Governance
The resolution of a GNS name must start in a given start zone
@@ -1164,20 +1161,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 21]
-
-Internet-Draft The GNU Name System November 2019
-
-
Example name: www.example.gnu
Local zones:
fr = (d0,zk0)
@@ -1187,6 +1170,14 @@ Internet-Draft The GNU Name System November 2019
=> Entry zone: zk1
=> Name to resolve from entry zone: www.example
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 21]
+
+Internet-Draft The GNU Name System November 2019
+
+
Finally, additional "suffix to zone" mappings MAY be configured.
Suffix to zone key mappings SHOULD be configurable through a local
configuration file or database by the user or system administrator.
@@ -1212,7 +1203,48 @@ Internet-Draft The GNU Name System November 2019
10. IANA Considerations
- This will be fun
+ IANA is requested to create an "GNU Name System Record Type"
+ registry. The registry shall record for each entry:
+
+ * Type: The name of the record type (case insensitive ASCII string,
+ restricted to alphanumeric characters
+
+ * Number: 32-bit, above 65535
+
+ * Contact: The contact information of a person to contact for
+ further information
+
+ * References: Optionally, references describing the record type
+ (such as an RFC)
+
+ The registration policy for this sub-registry is "First Come First
+ Served", as described in [RFC8126]. IANA is requested to populate
+ this registry as follows:
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 22]
+
+Internet-Draft The GNU Name System November 2019
+
+
+ Number | Type | Contact | References
+ ---------+-----------------+---------+---------
+ 65536 | PKEY | N/A | [This.I-D]
+ 65537 | NICK | N/A | [This.I-D]
+ 65538 | LEHO | N/A | [This.I-D]
+ 65539 | VPN | N/A | [This.I-D]
+ 65540 | GNS2DNS | N/A | [This.I-D]
+ 65541 | BOX | N/A | [This.I-D]
+ FIXME We have a lot more?
+
+ Figure 17
11. Test Vectors
@@ -1227,13 +1259,6 @@ Internet-Draft The GNU Name System November 2019
f89333903b284fe8
1878bf47f3b39da0
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 22]
-
-Internet-Draft The GNU Name System November 2019
-
-
zk (public zone key) :=
dff911496d025d7e
0885c03d19153e99
@@ -1257,6 +1282,14 @@ Internet-Draft The GNU Name System November 2019
0017c802f7d32e18
q (query key) :=
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 23]
+
+Internet-Draft The GNU Name System November 2019
+
+
6fce4deddc5ad681
f4e29a3310767e3b
8b38bc1b276ce2ba
@@ -1282,14 +1315,6 @@ Internet-Draft The GNU Name System November 2019
3425e8a811ae59d2
99e2747285d2a479
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 23]
-
-Internet-Draft The GNU Name System November 2019
-
-
TWOFISH_IV :=
071be189a9d236f9
b4a3654bb8c281d4
@@ -1313,6 +1338,14 @@ Internet-Draft The GNU Name System November 2019
afc99ba9c5a3bb54
07e731a34680ee33
ae0de7bfeda7d2b7
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 24]
+
+Internet-Draft The GNU Name System November 2019
+
+
8c6b854a008b1b54
10df4f39f5ba9f46____________
8cb514a56c0eaae0 zk_h
@@ -1337,15 +1370,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 24]
-
-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>.
@@ -1370,6 +1394,14 @@ Internet-Draft The GNU Name System November 2019
DOI 10.17487/RFC3826, June 2004,
<https://www.rfc-editor.org/info/rfc3826>.
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 25]
+
+Internet-Draft The GNU Name System November 2019
+
+
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
@@ -1394,14 +1426,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 25]
-
-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>.
@@ -1411,6 +1435,11 @@ Internet-Draft The GNU Name System November 2019
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
+ [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+ Writing an IANA Considerations Section in RFCs", BCP 26,
+ RFC 8126, DOI 10.17487/RFC8126, June 2017,
+ <https://www.rfc-editor.org/info/rfc8126>.
+
[TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A
128-Bit Block Cipher, 1st Edition", March 1999.
@@ -1420,6 +1449,15 @@ Internet-Draft The GNU Name System November 2019
Authors' Addresses
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 26]
+
+Internet-Draft The GNU Name System November 2019
+
+
Martin Schanzenbach
GNUnet e.V.
Boltzmannstrasse 3
@@ -1453,4 +1491,22 @@ Authors' Addresses
-Schanzenbach, et al. Expires 13 May 2020 [Page 26]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 27]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -13,6 +13,7 @@
<!ENTITY RFC6979 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml">
<!ENTITY RFC7748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7748.xml">
<!ENTITY RFC8032 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml">
+<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
@@ -285,25 +286,12 @@
<section anchor="gnsrecords_numbers" numbered="true" toc="default">
<name>Record Types</name>
<t>
- GNS-specific record type numbers start at 2^16, i.e. after the record
- type numbers for DNS. The following is a list of defined and reserved
- record types in GNS:
+ A registry of GNS Record Types is described in Section 10. The
+ registration policy for this registry is "First Come First Served", as
+ described in <xref target="RFC8126"/>. When requesting new entries, careful
+ consideration of the following criteria is strongly advised:
+ FIXME: ausdenken was wir da gerne haetten.
</t>
- <figure anchor="figure_rrtypenums">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- Number | Type | Comment
- ------------------------------------------------------------
- 65536 | PKEY | GNS delegation
- 65537 | NICK | GNS zone nickname
- 65538 | LEHO | Legacy hostname
- 65539 | VPN | Virtual private network
- 65540 | GNS2DNS | DNS delegation
- 65541 | BOX | Boxed record (for TLSA/SRV)
- 65542 up to 2^24 - 1 | - | Reserved
- 2^24 up to 2^32 - 1 | - | Unassigned / For private use
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
</section>
<section anchor="gnsrecords_pkey" numbered="true" toc="default">
<name>PKEY</name>
@@ -418,10 +406,12 @@
Nickname records can be used by zone administrators to publish an
indication on what label this zone prefers to be referred to.
This is a suggestion to other zones what label to use when creating a
- PKEY <xref target="gnsrecords_pkey" /> record containing this zone's
+ PKEY (<xref target="gnsrecords_pkey" />) record containing this zone's
public zone key.
This record SHOULD only be stored under the empty label "@" but MAY be
returned with record sets under any label as a supplemental record.
+ <xref target="nick_processing"/> details how a resolver must process
+ supplemental and non-supplemental NICK records.
A NICK DATA entry has the following format:
</t>
<figure anchor="figure_nickrecord">
@@ -1071,22 +1061,22 @@
does not support setting up a tunnnel.
</t>
</section>
- <section anchor="suppl_processing" numbered="true" toc="default">
- <name>Supplemental Records</name>
+ <section anchor="nick_processing" numbered="true" toc="default">
+ <name>NICK</name>
<t>
- Supplemental records are only relevant to the recursive resolver
+ NIICK 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.
+ be returned to the client. The encountered NICK records may either
+ be supplemental (see <xref target="rrecords"/>) or
+ non-supplemental.
+ If the NICK record is supplemental, the resolver only returns the
+ record set if one of the non-supplemental records matches the
+ queried record type.
</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:
+ NICK 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[
@@ -1276,8 +1266,38 @@
<section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>
- This will be fun
+ IANA is requested to create an "GNU Name System Record Type" registry.
+The registry shall record for each entry:
+ </t>
+ <ul>
+ <li>Type: The name of the record type (case insensitive ASCII
+ string, restricted to alphanumeric characters</li>
+ <li>Number: 32-bit, above 65535</li>
+ <li>Contact: The contact information of a person to contact for
+ further information</li>
+ <li>References: Optionally, references describing the record type
+ (such as an RFC)</li>
+ </ul>
+ <t>
+ The registration policy for this sub-registry is "First Come First
+ Served", as described in <xref target="RFC8126"/>.
+ IANA is requested to populate this registry as follows:
</t>
+ <figure anchor="figure_rrtypenums">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ Number | Type | Contact | References
+ ---------+-----------------+---------+---------
+ 65536 | PKEY | N/A | [This.I-D]
+ 65537 | NICK | N/A | [This.I-D]
+ 65538 | LEHO | N/A | [This.I-D]
+ 65539 | VPN | N/A | [This.I-D]
+ 65540 | GNS2DNS | N/A | [This.I-D]
+ 65541 | BOX | N/A | [This.I-D]
+ FIXME We have a lot more?
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+
</section>
<!-- iana -->
<section>
@@ -1404,6 +1424,7 @@
&RFC6979;
&RFC7748;
&RFC8032;
+ &RFC8126;
<reference anchor="TWOFISH">
<front>
