commit 7ec725013d657e2cddfff031091f20983c813986
parent 050c36f8b667809ebc282b2a718e3322d128ec6b
Author: Schanzenbach, Martin <mschanzenbach@posteo.de>
Date: Sat, 5 Oct 2019 13:32:23 +0200
more resulution WIP
Diffstat:
3 files changed, 196 insertions(+), 185 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
@@ -1098,7 +1098,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</ul>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.4">
- <p id="section-boilerplate.3-1.4.1"><a href="#section-4" class="xref">4</a>. <a href="#name-publishing-records" class="xref">Publishing records</a><a href="#section-boilerplate.3-1.4.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.4.1"><a href="#section-4" class="xref">4</a>. <a href="#name-publishing-records" class="xref">Publishing Records</a><a href="#section-boilerplate.3-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.4.2.1">
<p id="section-boilerplate.3-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>. <a href="#name-key-derivations" class="xref">Key derivations</a><a href="#section-boilerplate.3-1.4.2.1.1" class="pilcrow">¶</a></p>
@@ -1115,13 +1115,16 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<p id="section-boilerplate.3-1.5.1"><a href="#section-5" class="xref">5</a>. <a href="#name-internationalization-and-ch" class="xref">Internationalization and Character Encoding</a><a href="#section-boilerplate.3-1.5.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.6">
- <p id="section-boilerplate.3-1.6.1"><a href="#section-6" class="xref">6</a>. <a href="#name-record-resolution" class="xref">Record Resolution</a><a href="#section-boilerplate.3-1.6.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.6.1"><a href="#section-6" class="xref">6</a>. <a href="#name-name-resolution" class="xref">Name Resolution</a><a href="#section-boilerplate.3-1.6.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.1">
<p id="section-boilerplate.3-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>. <a href="#name-entry-zone" class="xref">Entry Zone</a><a href="#section-boilerplate.3-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.2">
- <p id="section-boilerplate.3-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>. <a href="#name-recursive-resolution" class="xref">Recursive Resolution</a><a href="#section-boilerplate.3-1.6.2.2.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>. <a href="#name-record-retrieval" class="xref">Record Retrieval</a><a href="#section-boilerplate.3-1.6.2.2.1" class="pilcrow">¶</a></p>
+</li>
+ <li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.3">
+ <p id="section-boilerplate.3-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>. <a href="#name-record-processing" class="xref">Record Processing</a><a href="#section-boilerplate.3-1.6.2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
@@ -1551,14 +1554,16 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<div id="publish">
<section id="section-4">
<h2 id="name-publishing-records">
-<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-publishing-records" class="section-name selfRef">Publishing records</a>
+<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-publishing-records" class="section-name selfRef">Publishing Records</a>
</h2>
<p id="section-4-1">
GNS resource records are published in a distributed hash table (DHT).
- Resource records are grouped by their respective labels, encrypted and
- published together in a single block in the DHT.
- A resource records block is published under a key "q" which is derived
- from the zone key "zk" and the respective label of the contained records.<a href="#section-4-1" class="pilcrow">¶</a></p>
+ We assume that a DHT provides two functions: GET(key) and PUT(key,value).
+ In GNS, resource records are grouped by their respective labels,
+ encrypted and published together in a single resource records block
+ (RRBLOCK) in the DHT under a key "q": PUT(q, RRBLOCK).
+ The key "q" which is derived from the zone key "zk" and the respective
+ label of the contained records.<a href="#section-4-1" class="pilcrow">¶</a></p>
<div id="blinding">
<section id="section-4.1">
<h3 id="name-key-derivations">
@@ -1636,10 +1641,10 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
block in the DHT.
The contained resource records are encrypted using a symmetric
encryption scheme.
- A GNS implementation must publish resource record blocks in accordance
- to the properties and recommendations of the underlying DHT. This may
- include a periodic refresh publication.
- A GNS resource records block has the following format:<a href="#section-4.2-1" class="pilcrow">¶</a></p>
+ A GNS implementation must publish RRBLOCKs
+ in accordance to the properties and recommendations of the underlying
+ 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-8">
<div class="artwork art-text alignLeft" id="section-4.2-2.1">
@@ -1705,7 +1710,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</dd>
<dt id="section-4.2-4.9">EXPIRATION</dt>
<dd id="section-4.2-4.10">
- Specifies when the resource records block expires and the encrypted block
+ Specifies when the RRBLOCK expires and the encrypted block
SHOULD be removed from the DHT and caches as it is likely stale.
However, applications MAY continue to use non-expired individual
records until they expire. The value MUST be set to the
@@ -1730,7 +1735,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</h3>
<p id="section-4.3-1">
A symmetric encryption scheme is used to encrypt the resource records
- set RDATA into the BDATA field of a GNS record block.
+ 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-9">
@@ -1789,28 +1794,19 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</dd>
</dl>
<p id="section-4.3-5">
- To obtain a given resource records block, the client must first compute
- "zk_h" from "zk"
- and label (as defined in <a href="#blinding" class="xref">Section 4.1</a>)
- and then use "zk_h" to compute "q" which is the query for the DHT.
- Upon receiving a block from the DHT, the receiver first checks
- that the PUBLIC KEY field matches "zk_h". Then, the client MUST verify
- the signature. These steps are mandatory to prevent record spoofing and
- MUST be performed before decryption.<a href="#section-4.3-5" class="pilcrow">¶</a></p>
-<p id="section-4.3-6">
The symmetric keys and initialization vectors are derived from the
record label and the zone key "zk". For decryption of the resource
records block payload, the key material "K" and initialization vector
- "IV" for the symmetric cipher are derived as follows:<a href="#section-4.3-6" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-4.3-7">
+ "IV" for the symmetric cipher are derived as follows:<a href="#section-4.3-5" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-4.3-6">
<pre>
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
K := HKDF-Expand (PRK_k, label, 512 / 8);
IV := HKDF-Expand (PRK_iv, label, 256 / 8)
- </pre><a href="#section-4.3-7" class="pilcrow">¶</a>
+ </pre><a href="#section-4.3-6" class="pilcrow">¶</a>
</div>
-<p id="section-4.3-8">
+<p id="section-4.3-7">
HKDF is a hash-based key derivation function as defined in
<span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>. Specifically, HMAC-SHA512 is used for the
extraction phase and HMAC-SHA256 for the expansion phase.
@@ -1818,10 +1814,10 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
keys and 32 octets (256 bit) for the initialization vectors.
We divide the resulting keying material "K" into a 256-bit AES
<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-8" class="pilcrow">¶</a></p>
+ 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-10">
- <div class="artwork art-text alignLeft" id="section-4.3-9.1">
+ <div class="artwork art-text alignLeft" id="section-4.3-8.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1839,12 +1835,12 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</div>
<figcaption><a href="#figure-10" class="selfRef">Figure 10</a></figcaption></figure>
</div>
-<p id="section-4.3-10">
+<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-10" class="pilcrow">¶</a></p>
+ and a 128-bit initialization vector:<a href="#section-4.3-9" class="pilcrow">¶</a></p>
<div id="figure_hkdf_ivs">
<figure id="figure-11">
- <div class="artwork art-text alignLeft" id="section-4.3-11.1">
+ <div class="artwork art-text alignLeft" id="section-4.3-10.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1858,15 +1854,15 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</div>
<figcaption><a href="#figure-11" class="selfRef">Figure 11</a></figcaption></figure>
</div>
-<p id="section-4.3-12">
+<p id="section-4.3-11">
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 (CFB) mode <span>[<a href="#RFC3826" class="xref">RFC3826</a>]</span>.<a href="#section-4.3-12" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-4.3-13">
+ Cipher FeedBack (CFB) mode <span>[<a href="#RFC3826" class="xref">RFC3826</a>]</span>.<a href="#section-4.3-11" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-4.3-12">
<pre>
RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV, BDATA))
BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV, RDATA))
- </pre><a href="#section-4.3-13" class="pilcrow">¶</a>
+ </pre><a href="#section-4.3-12" class="pilcrow">¶</a>
</div>
</section>
</section>
@@ -1885,8 +1881,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</div>
<div id="resolution">
<section id="section-6">
- <h2 id="name-record-resolution">
-<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-record-resolution" class="section-name selfRef">Record Resolution</a>
+ <h2 id="name-name-resolution">
+<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-name-resolution" class="section-name selfRef">Name Resolution</a>
</h2>
<p id="section-6-1">
TODO<a href="#section-6-1" class="pilcrow">¶</a></p>
@@ -1956,10 +1952,10 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</div>
</section>
</div>
-<div id="recursion">
+<div id="record_retrieval">
<section id="section-6.2">
- <h3 id="name-recursive-resolution">
-<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-recursive-resolution" class="section-name selfRef">Recursive Resolution</a>
+ <h3 id="name-record-retrieval">
+<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-record-retrieval" class="section-name selfRef">Record Retrieval</a>
</h3>
<p id="section-6.2-1">
In order to resolve a name in GNS, a type MAY be given.
@@ -1975,25 +1971,38 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</li>
<li id="section-6.2-3.2">Calculate q using the label and zk.<a href="#section-6.2-3.2" class="pilcrow">¶</a>
</li>
- <li id="section-6.2-3.3">Perform a DHT query GET(q) to retrieve the record set.<a href="#section-6.2-3.3" class="pilcrow">¶</a>
+ <li id="section-6.2-3.3">Perform a DHT query GET(q) to retrieve the RRBLOCK.<a href="#section-6.2-3.3" class="pilcrow">¶</a>
</li>
- <li id="section-6.2-3.4">Decrypt and verify the record set.<a href="#section-6.2-3.4" class="pilcrow">¶</a>
+ <li id="section-6.2-3.4">Verify the RRBLOCK and decrypt the BDATA contained in it.<a href="#section-6.2-3.4" class="pilcrow">¶</a>
</li>
</ol>
<p id="section-6.2-4">
+ Upon receiving the RRBLOCK from the DHT, apart from verifying the
+ provided signature, the resolver MUST check that the authoritative
+ zone key was used to sign the record:
+ The derived zone key "h*zk" must match the public key provided in
+ the RRBLOCK.<a href="#section-6.2-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="record_processing">
+<section id="section-6.3">
+ <h3 id="name-record-processing">
+<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-record-processing" class="section-name selfRef">Record Processing</a>
+ </h3>
+<p id="section-6.3-1">
If the remainder of the name to resolve is not empty, the records
result MUST consist of a single PKEY record. The recursion is then
- continued with the PKEY record value as new authoritative zone.<a href="#section-6.2-4" class="pilcrow">¶</a></p>
-<p id="section-6.2-5">
+ continued with the PKEY record value as new authoritative zone.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
+<p id="section-6.3-2">
If the remainder of the name to resolve is empty but we have received
a record set containing only a single PKEY record, the recursion is
continued with the PKEY as authoritative zone and the empty apex
label "@" as remaining name. If the record type to be resolved is
- PKEY, the PKEY record set is returned and the resolution is concluded.<a href="#section-6.2-5" class="pilcrow">¶</a></p>
-<p id="section-6.2-6">
+ PKEY, the PKEY record set is returned and the resolution is concluded.<a href="#section-6.3-2" class="pilcrow">¶</a></p>
+<p id="section-6.3-3">
If the remainder of the name to resolve is empty and the records set
does not consist of a PKEY record, the record set is the result and
- the resolution is concluded.<a href="#section-6.2-6" class="pilcrow">¶</a></p>
+ the resolution is concluded.<a href="#section-6.3-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
@@ -68,18 +68,19 @@ Table of Contents
3.3. LEHO . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. NICK . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 4. Publishing records . . . . . . . . . . . . . . . . . . . . . 8
+ 4. Publishing Records . . . . . . . . . . . . . . . . . . . . . 8
4.1. Key derivations . . . . . . . . . . . . . . . . . . . . . 8
4.2. Resource records block . . . . . . . . . . . . . . . . . 9
4.3. Block data encryption and decryption . . . . . . . . . . 11
5. Internationalization and Character Encoding . . . . . . . . . 13
- 6. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 13
- 6.1. Entry Zone . . . . . . . . . . . . . . . . . . . . . . . 14
- 6.2. Recursive Resolution . . . . . . . . . . . . . . . . . . 15
+ 6. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 13
+ 6.1. Entry Zone . . . . . . . . . . . . . . . . . . . . . . . 13
+ 6.2. Record Retrieval . . . . . . . . . . . . . . . . . . . . 14
+ 6.3. Record Processing . . . . . . . . . . . . . . . . . . . . 15
7. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 15
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
- 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
+ 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
@@ -108,7 +109,6 @@ Table of Contents
-
Schanzenbach, et al. Expires 24 January 2020 [Page 2]
Internet-Draft The GNU Name System July 2019
@@ -423,13 +423,15 @@ Internet-Draft The GNU Name System July 2019
RECORD DATA is a variable length field containing the "DATA" format
of TYPE as defined for the respective TYPE in DNS.
-4. Publishing records
+4. Publishing Records
GNS resource records are published in a distributed hash table (DHT).
- Resource records are grouped by their respective labels, encrypted
- and published together in a single block in the DHT. A resource
- records block is published under a key "q" which is derived from the
- zone key "zk" and the respective label of the contained records.
+ We assume that a DHT provides two functions: GET(key) and
+ PUT(key,value). In GNS, resource records are grouped by their
+ respective labels, encrypted and published together in a single
+ resource records block (RRBLOCK) in the DHT under a key "q": PUT(q,
+ RRBLOCK). The key "q" which is derived from the zone key "zk" and
+ the respective label of the contained records.
4.1. Key derivations
@@ -443,8 +445,6 @@ Internet-Draft The GNU Name System July 2019
-
-
Schanzenbach, et al. Expires 24 January 2020 [Page 8]
Internet-Draft The GNU Name System July 2019
@@ -487,10 +487,10 @@ Internet-Draft The GNU Name System July 2019
GNS records are grouped by their labels and published as a single
block in the DHT. The contained resource records are encrypted using
a symmetric encryption scheme. A GNS implementation must publish
- resource record blocks in accordance to the properties and
- recommendations of the underlying DHT. This may include a periodic
- refresh publication. A GNS resource records block has the following
- format:
+ RRBLOCKs in accordance to the properties and recommendations of the
+ underlying DHT. This may include a periodic refresh publication. A
+ GNS RRBLOCK has the following format:
+
@@ -562,12 +562,12 @@ Schanzenbach, et al. Expires 24 January 2020 [Page 10]
Internet-Draft The GNU Name System July 2019
- EXPIRATION Specifies when the resource records block expires and the
- encrypted block SHOULD be removed from the DHT and caches as it is
- likely stale. However, applications MAY continue to use non-
- expired individual records until they expire. The value MUST be
- set to the expiration time of the resource record contained within
- this block with the smallest expiration time. If a records block
+ EXPIRATION Specifies when the RRBLOCK expires and the encrypted
+ block SHOULD be removed from the DHT and caches as it is likely
+ stale. However, applications MAY continue to use non-expired
+ individual records until they expire. The value MUST be set to
+ the expiration time of the resource record contained within this
+ block with the smallest expiration time. If a records block
includes shadow records, then the maximum expiration time of all
shadow records with matching type and the expiration times of the
non-shadow records is considered. This is a 64-bit absolute date
@@ -579,8 +579,8 @@ Internet-Draft The GNU Name System July 2019
4.3. Block data encryption and decryption
A symmetric encryption scheme is used to encrypt the resource records
- set RDATA into the BDATA field of a GNS record block. The wire
- format of the RDATA looks as follows:
+ set RDATA into the BDATA field of a GNS RRBLOCK. The wire format of
+ the RDATA looks as follows:
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -632,14 +632,6 @@ Internet-Draft The GNU Name System July 2019
sets with (only) a PKEY record type are never padded. Note that a
record set with a PKEY record MUST NOT contain other records.
- To obtain a given resource records block, the client must first
- compute "zk_h" from "zk" and label (as defined in Section 4.1) and
- then use "zk_h" to compute "q" which is the query for the DHT. Upon
- receiving a block from the DHT, the receiver first checks that the
- PUBLIC KEY field matches "zk_h". Then, the client MUST verify the
- signature. These steps are mandatory to prevent record spoofing and
- MUST be performed before decryption.
-
The symmetric keys and initialization vectors are derived from the
record label and the zone key "zk". For decryption of the resource
records block payload, the key material "K" and initialization vector
@@ -658,22 +650,6 @@ Internet-Draft The GNU Name System July 2019
"K" into a 256-bit AES [RFC3826] key and a 256-bit TWOFISH [TWOFISH]
key:
-
-
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 12]
-
-Internet-Draft The GNU Name System July 2019
-
-
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| AES KEY |
@@ -689,6 +665,15 @@ Internet-Draft The GNU Name System July 2019
Figure 10
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 12]
+
+Internet-Draft The GNU Name System July 2019
+
+
Similarly, we divide "IV" into a 128-bit initialization vector and a
128-bit initialization vector:
@@ -717,19 +702,10 @@ Internet-Draft The GNU Name System July 2019
which are internationalized through the IDNA specifications
[RFC5890].
-6. Record Resolution
+6. Name Resolution
TODO
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 13]
-
-Internet-Draft The GNU Name System July 2019
-
-
6.1. Entry Zone
There are three sources from which the entry zone can be determined
@@ -745,6 +721,15 @@ Internet-Draft The GNU Name System July 2019
If the TLD is a Base32-encoded public zone key "zk", the entry zone
of the resolution process is implicitly given by the name.
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 13]
+
+Internet-Draft The GNU Name System July 2019
+
+
Example name: www.example.<Base32(zk)>
=> Entry zone: zk
=> Name to resolve from entry zone: www.example
@@ -771,21 +756,6 @@ Internet-Draft The GNU Name System July 2019
length of two results cannot be equal, as this would indicate a
misconfiguration.
-
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 14]
-
-Internet-Draft The GNU Name System July 2019
-
-
Example name: www.example.gnu
Local prefix mappings:
gnu = zk0
@@ -795,7 +765,7 @@ Internet-Draft The GNU Name System July 2019
=> Entry zone: zk1
=> Name to resolve from entry zone: www
-6.2. Recursive Resolution
+6.2. Record Retrieval
In order to resolve a name in GNS, a type MAY be given. However,
filtering of record results according to type is done after the
@@ -808,11 +778,26 @@ Internet-Draft The GNU Name System July 2019
1. Extract the right-most label from the name to look up.
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 14]
+
+Internet-Draft The GNU Name System July 2019
+
+
2. Calculate q using the label and zk.
- 3. Perform a DHT query GET(q) to retrieve the record set.
+ 3. Perform a DHT query GET(q) to retrieve the RRBLOCK.
+
+ 4. Verify the RRBLOCK and decrypt the BDATA contained in it.
- 4. Decrypt and verify the record set.
+ Upon receiving the RRBLOCK from the DHT, apart from verifying the
+ provided signature, the resolver MUST check that the authoritative
+ zone key was used to sign the record: The derived zone key "h*zk"
+ must match the public key provided in the RRBLOCK.
+
+6.3. Record Processing
If the remainder of the name to resolve is not empty, the records
result MUST consist of a single PKEY record. The recursion is then
@@ -833,15 +818,6 @@ Internet-Draft The GNU Name System July 2019
TODO
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 15]
-
-Internet-Draft The GNU Name System July 2019
-
-
8. Security Considerations
TODO
@@ -855,6 +831,17 @@ Internet-Draft The GNU Name System July 2019
The following represents a test vector for a record of type MX with a
priority of 10 and the mail hostname mail.example.com.
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 15]
+
+Internet-Draft The GNU Name System July 2019
+
+
label := "mail"
d :=
@@ -890,14 +877,6 @@ Internet-Draft The GNU Name System July 2019
f4e29a3310767e3b
8b38bc1b276ce2ba
9bf1b49df1e120a3
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 16]
-
-Internet-Draft The GNU Name System July 2019
-
-
20ecc9dffb68416f
11729ad878ad3bdf
d0b4db2626b620d7
@@ -911,6 +890,14 @@ Internet-Draft The GNU Name System July 2019
AES_IV :=
a808b929bc9fad7a
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 16]
+
+Internet-Draft The GNU Name System July 2019
+
+
686bbe3432bed77a
TWOFISH_KEY :=
@@ -946,14 +933,6 @@ Internet-Draft The GNU Name System July 2019
10df4f39f5ba9f46____________
8cb514a56c0eaae0 zk_h
56745158a63ee4dd
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 17]
-
-Internet-Draft The GNU Name System July 2019
-
-
76853cb9545e326e
76d7fa920f818291____________
000000540000000f SIZE (=84) | PURPOSE (=15)
@@ -968,6 +947,13 @@ Internet-Draft The GNU Name System July 2019
001fd19a6406a721
713f0a0d
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 17]
+
+Internet-Draft The GNU Name System July 2019
+
+
11. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
@@ -1003,13 +989,6 @@ Internet-Draft The GNU Name System July 2019
DOI 10.17487/RFC5891, August 2010,
<https://www.rfc-editor.org/info/rfc5891>.
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 18]
-
-Internet-Draft The GNU Name System July 2019
-
-
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
April 2013, <https://www.rfc-editor.org/info/rfc6895>.
@@ -1023,6 +1002,14 @@ Internet-Draft The GNU Name System July 2019
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 18]
+
+Internet-Draft The GNU Name System July 2019
+
+
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
@@ -1061,4 +1048,17 @@ Authors' Addresses
+
+
+
+
+
+
+
+
+
+
+
+
+
Schanzenbach, et al. Expires 24 January 2020 [Page 19]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -428,13 +428,15 @@
</section>
<section anchor="publish" numbered="true" toc="default">
- <name>Publishing records</name>
+ <name>Publishing Records</name>
<t>
GNS resource records are published in a distributed hash table (DHT).
- Resource records are grouped by their respective labels, encrypted and
- published together in a single block in the DHT.
- A resource records block is published under a key "q" which is derived
- from the zone key "zk" and the respective label of the contained records.
+ We assume that a DHT provides two functions: GET(key) and PUT(key,value).
+ In GNS, resource records are grouped by their respective labels,
+ encrypted and published together in a single resource records block
+ (RRBLOCK) in the DHT under a key "q": PUT(q, RRBLOCK).
+ The key "q" which is derived from the zone key "zk" and the respective
+ label of the contained records.
</t>
<section anchor="blinding" numbered="true" toc="default">
<name>Key derivations</name>
@@ -507,10 +509,10 @@
block in the DHT.
The contained resource records are encrypted using a symmetric
encryption scheme.
- A GNS implementation must publish resource record blocks in accordance
- to the properties and recommendations of the underlying DHT. This may
- include a periodic refresh publication.
- A GNS resource records block has the following format:
+ A GNS implementation must publish RRBLOCKs
+ in accordance to the properties and recommendations of the underlying
+ DHT. This may include a periodic refresh publication.
+ A GNS RRBLOCK has the following format:
</t>
<figure anchor="figure_record_block">
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -574,7 +576,7 @@
</dd>
<dt>EXPIRATION</dt>
<dd>
- Specifies when the resource records block expires and the encrypted block
+ Specifies when the RRBLOCK expires and the encrypted block
SHOULD be removed from the DHT and caches as it is likely stale.
However, applications MAY continue to use non-expired individual
records until they expire. The value MUST be set to the
@@ -596,7 +598,7 @@
<name>Block data encryption and decryption</name>
<t>
A symmetric encryption scheme is used to encrypt the resource records
- set RDATA into the BDATA field of a GNS record block.
+ set RDATA into the BDATA field of a GNS RRBLOCK.
The wire format of the RDATA looks as follows:
</t>
<figure anchor="figure_rdata">
@@ -654,16 +656,6 @@
</dl>
<t>
- To obtain a given resource records block, the client must first compute
- "zk_h" from "zk"
- and label (as defined in <xref target="blinding" />)
- and then use "zk_h" to compute "q" which is the query for the DHT.
- Upon receiving a block from the DHT, the receiver first checks
- that the PUBLIC KEY field matches "zk_h". Then, the client MUST verify
- the signature. These steps are mandatory to prevent record spoofing and
- MUST be performed before decryption.
- </t>
- <t>
The symmetric keys and initialization vectors are derived from the
record label and the zone key "zk". For decryption of the resource
records block payload, the key material "K" and initialization vector
@@ -746,7 +738,7 @@
</t>
</section>
<section anchor="resolution" numbered="true" toc="default">
- <name>Record Resolution</name>
+ <name>Name Resolution</name>
<t>
TODO
</t>
@@ -809,8 +801,8 @@
=> Name to resolve from entry zone: www
]]></artwork>
</section>
- <section anchor="recursion" numbered="true" toc="default">
- <name>Recursive Resolution</name>
+ <section anchor="record_retrieval" numbered="true" toc="default">
+ <name>Record Retrieval</name>
<t>
In order to resolve a name in GNS, a type MAY be given.
However, filtering of record results according to type is done after
@@ -825,10 +817,20 @@
<ol>
<li>Extract the right-most label from the name to look up.</li>
<li>Calculate q using the label and zk.</li>
- <li>Perform a DHT query GET(q) to retrieve the record set.</li>
- <li>Decrypt and verify the record set.</li>
+ <li>Perform a DHT query GET(q) to retrieve the RRBLOCK.</li>
+ <li>Verify the RRBLOCK and decrypt the BDATA contained in it.</li>
</ol>
<t>
+ Upon receiving the RRBLOCK from the DHT, apart from verifying the
+ provided signature, the resolver MUST check that the authoritative
+ zone key was used to sign the record:
+ The derived zone key "h*zk" must match the public key provided in
+ the RRBLOCK.
+ </t>
+ </section>
+ <section anchor="record_processing" numbered="true" toc="default">
+ <name>Record Processing</name>
+ <t>
If the remainder of the name to resolve is not empty, the records
result MUST consist of a single PKEY record. The recursion is then
continued with the PKEY record value as new authoritative zone.
