[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: security considerations
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated: security considerations |
|
Date: |
Sat, 16 May 2020 18:41:21 +0200 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a commit to branch master
in repository lsd0001.
The following commit(s) were added to refs/heads/master by this push:
new bca9933 security considerations
bca9933 is described below
commit bca9933cd1260b48d4b8ae9cf6bb6d12820f8a62
Author: Martin Schanzenbach <address@hidden>
AuthorDate: Sat May 16 18:36:16 2020 +0200
security considerations
---
draft-schanzen-gns.html | 587 +++++++++++++++++++++++++--------------------
draft-schanzen-gns.txt | 618 ++++++++++++++++++++++++++----------------------
draft-schanzen-gns.xml | 578 +++++++++++++++++++++++++-------------------
3 files changed, 992 insertions(+), 791 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 157ba24..f9d94d1 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -1232,13 +1232,13 @@ table {
<p id="section-toc.1-1.9.1"><a href="#section-9"
class="xref">9</a>. <a href="#name-security-considerations"
class="xref">Security Considerations</a><a href="#section-toc.1-1.9.1"
class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.9.2.1">
- <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1"
class="xref">9.1</a>. <a href="#name-abuse-mitigation" class="xref">Abuse
mitigation</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
+ <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1"
class="xref">9.1</a>. <a href="#name-cryptography"
class="xref">Cryptography</a><a href="#section-toc.1-1.9.2.1.1"
class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9.2.2">
- <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2"
class="xref">9.2</a>. <a href="#name-zone-key-management" class="xref">Zone
key management</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
+ <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2"
class="xref">9.2</a>. <a href="#name-abuse-mitigation" class="xref">Abuse
mitigation</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9.2.3">
- <p id="section-toc.1-1.9.2.3.1"><a href="#section-9.3"
class="xref">9.3</a>. <a href="#name-root-zone-management" class="xref">Root
zone management</a><a href="#section-toc.1-1.9.2.3.1" class="pilcrow">¶</a></p>
+ <p id="section-toc.1-1.9.2.3.1"><a href="#section-9.3"
class="xref">9.3</a>. <a href="#name-zone-management" class="xref">Zone
management</a><a href="#section-toc.1-1.9.2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9.2.4">
<p id="section-toc.1-1.9.2.4.1"><a href="#section-9.4"
class="xref">9.4</a>. <a href="#name-impact-of-underlying-dht"
class="xref">Impact of underlying DHT</a><a href="#section-toc.1-1.9.2.4.1"
class="pilcrow">¶</a></p>
@@ -1376,16 +1376,16 @@ table {
<figure id="figure-1">
<div class="artwork art-text alignLeft" id="section-3-3.1">
<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / /
- / /
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EXPIRATION |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| DATA SIZE | TYPE |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| FLAGS | DATA /
++-----+-----+-----+-----+ /
+/ /
+/ /
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure
1</a></figcaption></figure>
@@ -1432,10 +1432,10 @@ table {
<figure id="figure-2">
<div class="artwork art-text alignLeft" id="section-3-7.1">
<pre>
- ... 5 4 3 2 1 0
- ------+--------+--------+--------+--------+--------+
- / ... | SHADOW | EXPREL | SUPPL | PRIVATE| / |
- ------+--------+--------+--------+--------+--------+
+... 5 4 3 2 1 0
+------+--------+--------+--------+--------+--------+
+/ ... | SHADOW | EXPREL | SUPPL | PRIVATE| / |
+------+--------+--------+--------+--------+--------+
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure
2</a></figcaption></figure>
@@ -1503,13 +1503,13 @@ table {
<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
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| PUBLIC KEY |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure
3</a></figcaption></figure>
@@ -1538,18 +1538,18 @@ table {
<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
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DNS NAME |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DNS SERVER NAME |
- / /
- / /
- | |
- +-----------------------------------------------+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| DNS NAME |
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| DNS SERVER NAME |
+/ /
+/ /
+| |
++-----------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure
4</a></figcaption></figure>
@@ -1588,13 +1588,13 @@ table {
<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
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | LEGACY HOSTNAME |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| LEGACY HOSTNAME |
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure
5</a></figcaption></figure>
@@ -1633,13 +1633,13 @@ table {
<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
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | NICKNAME |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| NICKNAME |
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure
6</a></figcaption></figure>
@@ -1677,15 +1677,15 @@ table {
<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
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PROTO | SVC | TYPE |
- +-----------+-----------------------------------+
- | RECORD DATA |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| PROTO | SVC | TYPE |
++-----------+-----------------------------------+
+| RECORD DATA |
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure
7</a></figcaption></figure>
@@ -1725,19 +1725,19 @@ table {
<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
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | HOSTING PEER PUBLIC KEY |
- | (256 bits) |
- | |
- | |
- +-----------+-----------------------------------+
- | PROTO | SERVICE NAME |
- +-----------+ +
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| HOSTING PEER PUBLIC KEY |
+| (256 bits) |
+| |
+| |
++-----------+-----------------------------------+
+| PROTO | SERVICE NAME |
++-----------+ +
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
<figcaption><a href="#figure-8" class="selfRef">Figure
8</a></figcaption></figure>
@@ -1787,11 +1787,11 @@ table {
Given a label, the DHT key "q" is derived as follows:<a
href="#section-4.1-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.1-2">
<pre>
- PRK_h := HKDF-Extract ("key-derivation", zk)
- h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
- d_h := h * d mod L
- zk_h := h mod L * zk
- q := SHA512 (zk_h)
+PRK_h := HKDF-Extract ("key-derivation", zk)
+h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
+d_h := h * d mod L
+zk_h := h mod L * zk
+q := SHA512 (zk_h)
</pre><a href="#section-4.1-2" class="pilcrow">¶</a>
</div>
<p id="section-4.1-3">
@@ -1865,30 +1865,30 @@ table {
<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
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIGNATURE |
- | |
- | |
- | |
- | |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIZE | PURPOSE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | BDATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIGNATURE |
+| |
+| |
+| |
+| |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| PUBLIC KEY |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIZE | PURPOSE |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EXPIRATION |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| BDATA /
+/ /
+/ |
++-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
<figcaption><a href="#figure-9" class="selfRef">Figure
9</a></figcaption></figure>
@@ -1958,29 +1958,29 @@ table {
<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
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | RR COUNT | EXPIRA- /
- +-----+-----+-----+-----+-----+-----+-----+-----+
- / -TION | DATA SIZE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TYPE | FLAGS |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / +-----------------------/
- / | /
- +-----------------------+ /
- / PADDING /
- / /
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| RR COUNT | EXPIRA- /
++-----+-----+-----+-----+-----+-----+-----+-----+
+/ -TION | DATA SIZE |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| TYPE | FLAGS |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| DATA /
+/ /
+/ |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EXPIRATION |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| DATA SIZE | TYPE |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| FLAGS | DATA /
++-----+-----+-----+-----+ /
+/ +-----------------------/
+/ | /
++-----------------------+ /
+/ PADDING /
+/ /
</pre>
</div>
<figcaption><a href="#figure-10" class="selfRef">Figure
10</a></figcaption></figure>
@@ -2017,10 +2017,10 @@ table {
"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)
+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-6" class="pilcrow">¶</a>
</div>
<p id="section-4.3-7">
@@ -2036,18 +2036,18 @@ table {
<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
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| AES KEY |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| TWOFISH KEY |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
<figcaption><a href="#figure-11" class="selfRef">Figure
11</a></figcaption></figure>
@@ -2059,14 +2059,14 @@ table {
<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
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES IV |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH IV |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| AES IV |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| TWOFISH IV |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
<figcaption><a href="#figure-12" class="selfRef">Figure
12</a></figcaption></figure>
@@ -2077,10 +2077,10 @@ table {
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(K[0:31], IV[0:15],
- TWOFISH(K[32:63], IV[16:31], BDATA))
- BDATA := TWOFISH(K[32:63], IV[16:31],
- AES(K[0:31], IV[0:15], RDATA))
+RDATA := AES(K[0:31], IV[0:15],
+ TWOFISH(K[32:63], IV[16:31], BDATA))
+BDATA := TWOFISH(K[32:63], IV[16:31],
+ AES(K[0:31], IV[0:15], RDATA))
</pre><a href="#section-4.3-12" class="pilcrow">¶</a>
</div>
</section>
@@ -2349,10 +2349,10 @@ table {
<figure id="figure-13">
<div class="artwork art-text alignLeft" id="section-6.2.6-3.1">
<pre>
- Query: alice.doe (type=A)
- Result:
- A: 1.2.3.4
- NICK: eve
+Query: alice.doe (type=A)
+Result:
+A: 1.2.3.4
+NICK: eve
</pre>
</div>
<figcaption><a href="#figure-13" class="selfRef">Figure
13</a></figcaption></figure>
@@ -2366,10 +2366,10 @@ table {
<figure id="figure-14">
<div class="artwork art-text alignLeft" id="section-6.2.6-5.1">
<pre>
- Query: alice.doe (type=A)
- Result:
- A: 1.2.3.4
- NICK: john (Supplemental)
+Query: alice.doe (type=A)
+Result:
+A: 1.2.3.4
+NICK: john (Supplemental)
</pre>
</div>
<figcaption><a href="#figure-14" class="selfRef">Figure
14</a></figcaption></figure>
@@ -2412,14 +2412,14 @@ table {
following parameters:<a href="#section-7-3" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-7-4">
<pre>
- S := "gnunet-revocation-proof-of-work" /* Salt */
- t := 3 /* Iterations */
- m := 1024 /* Memory size, 1 MiB */
- T := 64 /* Tag (=output) length in bytes */
- p := 1 /* Parallelization parameter */
- v := 0x13 /* Version */
- y := 0 /* Type (Argon2d) */
- X, K is unused
+S := "gnunet-revocation-proof-of-work" /* Salt */
+t := 3 /* Iterations */
+m := 1024 /* Memory size, 1 MiB */
+T := 64 /* Tag (=output) length in bytes */
+p := 1 /* Parallelization parameter */
+v := 0x13 /* Version */
+y := 0 /* Type (Argon2d) */
+X, K is unused
</pre><a href="#section-7-4" class="pilcrow">¶</a>
</div>
<p id="section-7-5">
@@ -2429,17 +2429,17 @@ table {
<figure id="figure-15">
<div class="artwork art-text alignLeft" id="section-7-6.1">
<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | POW |
- +-----------------------------------------------+
- | TIMESTAMP |
- +-----------------------------------------------+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| POW |
++-----------------------------------------------+
+| TIMESTAMP |
++-----------------------------------------------+
+| PUBLIC KEY |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
<figcaption><a href="#figure-15" class="selfRef">Figure
15</a></figcaption></figure>
@@ -2500,32 +2500,32 @@ table {
<figure id="figure-16">
<div class="artwork art-text alignLeft" id="section-7-14.1">
<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TIMESTAMP |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TTL |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | POW_0 |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | ... |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | POW_Z-1 |
- +-----------------------------------------------+
- | SIGNATURE |
- | |
- | |
- | |
- | |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| TIMESTAMP |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| TTL |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| POW_0 |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| ... |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| POW_Z-1 |
++-----------------------------------------------+
+| SIGNATURE |
+| |
+| |
+| |
+| |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| PUBLIC KEY |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
<figcaption><a href="#figure-16" class="selfRef">Figure
16</a></figcaption></figure>
@@ -2576,17 +2576,17 @@ table {
<figure id="figure-17">
<div class="artwork art-text alignLeft" id="section-7-18.1">
<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIZE (0x30) | PURPOSE (0x03) |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TIMESTAMP |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIZE (0x30) | PURPOSE (0x03) |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| PUBLIC KEY |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| TIMESTAMP |
++-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
<figcaption><a href="#figure-17" class="selfRef">Figure
17</a></figcaption></figure>
@@ -2666,9 +2666,9 @@ table {
by the name:<a href="#section-8-4" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-8-5">
<pre>
- Example name: www.example.<Base32(zk)>
- => Root zone: zk
- => Name to resolve from root zone: www.example
+Example name: www.example.<Base32(zk)>
+=> Root zone: zk
+=> Name to resolve from root zone: www.example
</pre><a href="#section-8-5" class="pilcrow">¶</a>
</div>
<p id="section-8-6">
@@ -2681,14 +2681,14 @@ table {
resolution SHOULD start from the respective local zone:<a
href="#section-8-6" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-8-7">
<pre>
- Example name: www.example.gnu
- Local zones:
- fr = (d0,zk0)
- gnu = (d1,zk1)
- com = (d2,zk2)
- ...
- => Entry zone: zk1
- => Name to resolve from entry zone: www.example
+Example name: www.example.gnu
+Local zones:
+fr = (d0,zk0)
+gnu = (d1,zk1)
+com = (d2,zk2)
+...
+=> Entry zone: zk1
+=> Name to resolve from entry zone: www.example
</pre><a href="#section-8-7" class="pilcrow">¶</a>
</div>
<p id="section-8-8">
@@ -2703,14 +2703,14 @@ table {
for the same suffix, the locally managed zone MUST have priority.<a
href="#section-8-8" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-8-9">
<pre>
- Example name: www.example.gnu
- Local suffix mappings:
- gnu = zk0
- example.gnu = zk1
- example.com = zk2
- ...
- => Entry zone: zk1
- => Name to resolve from entry zone: www
+Example name: www.example.gnu
+Local suffix mappings:
+gnu = zk0
+example.gnu = zk1
+example.com = zk2
+...
+=> Entry zone: zk1
+=> Name to resolve from entry zone: www
</pre><a href="#section-8-9" class="pilcrow">¶</a>
</div>
</section>
@@ -2720,31 +2720,73 @@ table {
<h2 id="name-security-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a
href="#name-security-considerations" class="section-name selfRef">Security
Considerations</a>
</h2>
-<div id="security_abuse">
+<div id="security_crypto">
<section id="section-9.1">
- <h3 id="name-abuse-mitigation">
-<a href="#section-9.1" class="section-number selfRef">9.1. </a><a
href="#name-abuse-mitigation" class="section-name selfRef">Abuse mitigation</a>
+ <h3 id="name-cryptography">
+<a href="#section-9.1" class="section-number selfRef">9.1. </a><a
href="#name-cryptography" class="section-name selfRef">Cryptography</a>
</h3>
<p id="section-9.1-1">
- DNS abuse: Squatting, takedowns, homographs.<a
href="#section-9.1-1" class="pilcrow">¶</a></p>
+ The security of cryptographic systems depends on both the strength
of
+ the cryptographic algorithms chosen and the strength of the keys
used
+ with those algorithms. The security also depends on the engineering
+ of the protocol used by the system to ensure that there are no
+ non-cryptographic ways to bypass the security of the overall
system.<a href="#section-9.1-1" class="pilcrow">¶</a></p>
+<p id="section-9.1-2">
+ This document concerns itself with the selection of cryptographic
+ algorithms for use in GNS.
+ The algorithms identified in this document are not known to be
+ broken (in the cryptographic sense) at the current time, and
+ cryptographic research so far leads us to believe that they are
+ likely to remain secure into the foreseeable future. However, this
+ isn't necessarily forever, and it is expected that new revisions of
+ this document will be issued from time to time to reflect the
current
+ best practices in this area.<a href="#section-9.1-2"
class="pilcrow">¶</a></p>
</section>
</div>
-<div id="security_keymanagement">
+<div id="security_abuse">
<section id="section-9.2">
- <h3 id="name-zone-key-management">
-<a href="#section-9.2" class="section-number selfRef">9.2. </a><a
href="#name-zone-key-management" class="section-name selfRef">Zone key
management</a>
+ <h3 id="name-abuse-mitigation">
+<a href="#section-9.2" class="section-number selfRef">9.2. </a><a
href="#name-abuse-mitigation" class="section-name selfRef">Abuse mitigation</a>
</h3>
<p id="section-9.2-1">
- Users need to manage and protect zone keys.<a href="#section-9.2-1"
class="pilcrow">¶</a></p>
+ GNS names are UTF-8 strings. Consequently, GNS faces similar issues
+ with respect to name spoofing as DNS does for internationalized
+ domain names.
+ In DNS, attackers may register similar sounding or looking
+ names (see above) in order to execute phishing attacks.
+ GNS zone administrators must take into account this attack vector
and
+ incorporate rules in order to mitigate it.<a href="#section-9.2-1"
class="pilcrow">¶</a></p>
+<p id="section-9.2-2">
+ Further, DNS can be used to combat illegal content on the internet
+ by having the respective domains seized by authorities.
+ However, the same mechanisms can also be abused in order to impose
+ state censorship, which ist one of the motivations behind GNS.
+ Hence, such a seizure is, by design, difficult to impossible in
GNS.<a href="#section-9.2-2" class="pilcrow">¶</a></p>
</section>
</div>
-<div id="security_root">
+<div id="security_keymanagement">
<section id="section-9.3">
- <h3 id="name-root-zone-management">
-<a href="#section-9.3" class="section-number selfRef">9.3. </a><a
href="#name-root-zone-management" class="section-name selfRef">Root zone
management</a>
+ <h3 id="name-zone-management">
+<a href="#section-9.3" class="section-number selfRef">9.3. </a><a
href="#name-zone-management" class="section-name selfRef">Zone management</a>
</h3>
<p id="section-9.3-1">
- Users must manage local root zone (availability).<a
href="#section-9.3-1" class="pilcrow">¶</a></p>
+ In GNS, zone administrators need to manage and protect their zone
+ keys. Once a zone key is lost it cannot be recovered. Once it is
+ compromised it cannot be revoked (unless a revocation was
+ pre-calculated and is still available).
+ Zone administrators, and for GNS this includes end-users, are
+ required to responsibly and dilligently protect their cryptographic
+ keys.<a href="#section-9.3-1" class="pilcrow">¶</a></p>
+<p id="section-9.3-2">
+ Similarly, users are required to manage their local root zone.
+ In order to ensure integrity and availability or names, users must
+ ensure that their local root zone information is not compromised or
+ outdated.
+ It can be expected that the processing of zone revocations and an
+ initial root zone is provided with a GNS client implementation
+ ("drop shipping").
+ Extension and customization of the zone is at the full discretion of
+ the user.<a href="#section-9.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="security_dht">
@@ -2753,7 +2795,19 @@ table {
<a href="#section-9.4" class="section-number selfRef">9.4. </a><a
href="#name-impact-of-underlying-dht" class="section-name selfRef">Impact of
underlying DHT</a>
</h3>
<p id="section-9.4-1">
- Is significant.<a href="#section-9.4-1" class="pilcrow">¶</a></p>
+ This document does not specifiy the properties of the underlying
+ distributed hash table (DHT) which is required by any GNS
+ implementation. For implementors, it is important to note that
+ the properties of the DHT are directly inherited by the
+ GNS implementation. This includes both security as well as
+ other non-functional properties such as scalability and performance.
+ Implementors should take great care when selecting or implementing
+ a DHT for use in a GNS implementation.
+ DHTs with string security and performance guarantees exist
+ <span>[<a href="#R5N" class="xref">R5N</a>]</span>.
+ It should also be taken into consideration that GNS implementations
+ which build upon different DHT overlays are unlikely to be
+ interoperable with each other.<a href="#section-9.4-1"
class="pilcrow">¶</a></p>
</section>
</div>
<div id="security_rev">
@@ -2762,17 +2816,25 @@ table {
<a href="#section-9.5" class="section-number selfRef">9.5. </a><a
href="#name-revocations" class="section-name selfRef">Revocations</a>
</h3>
<p id="section-9.5-1">
- Revocation payloads do NOT include a 'new' key for key replacement.
- In inclusion of such a key would have two major disadvantages:<a
href="#section-9.5-1" class="pilcrow">¶</a></p>
+ Zone administrators are advised to pre-generate zone revocations
+ and securely store the revocation information in case the zone
+ key is lost, compromised or replaced in the furture.
+ Pre-calculated revocations may become invalid due to expirations
+ or protocol changes such as epoch adjustments.
+ Conseuquently, implementors and users must make precautions in order
+ to manage revocations accordingly.<a href="#section-9.5-1"
class="pilcrow">¶</a></p>
<p id="section-9.5-2">
+ Revocation payloads do NOT include a 'new' key for key replacement.
+ In inclusion of such a key would have two major disadvantages:<a
href="#section-9.5-2" class="pilcrow">¶</a></p>
+<p id="section-9.5-3">
If revocation is used after a private key was compromised,
allowing key replacement would be dangerous, because if an
adversary took over the private key, the adversary could then
broadcast a revocation with a key replacement. For the replacement,
the compromised owner would have no chance to issue even a
revocation. Thus, allowing a revocation message to replace a private
- key makes dealing with key compromise situations worse.<a
href="#section-9.5-2" class="pilcrow">¶</a></p>
-<p id="section-9.5-3">
+ key makes dealing with key compromise situations worse.<a
href="#section-9.5-3" class="pilcrow">¶</a></p>
+<p id="section-9.5-4">
Sometimes, key revocations are used with the objective of changing
cryptosystems. Migration to another cryptosystem by replacing keys
via a revocation message would only be secure as long as both
@@ -2781,7 +2843,7 @@ table {
running zones for both ciphersystems in parallel for a while. The
migration would conclude by revoking the legacy zone key only once
it is deemed no longer secure, and hopefully after most users have
- migrated to the replacement.<a href="#section-9.5-3"
class="pilcrow">¶</a></p>
+ migrated to the replacement.<a href="#section-9.5-4"
class="pilcrow">¶</a></p>
</section>
</div>
</section>
@@ -2818,14 +2880,14 @@ The registry shall record for each entry:<a
href="#section-10-1" class="pilcrow"
<figure id="figure-18">
<div class="artwork art-text alignLeft" id="section-10-4.1">
<pre>
- Number | Name | 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]
+Number | Name | Contact | References | Description
+-------+---------+---------+------------+-------------------------
+65536 | PKEY | N/A | [This.I-D] | GNS zone delegation
+65537 | NICK | N/A | [This.I-D] | GNS zone nickname
+65538 | LEHO | N/A | [This.I-D] | GNS legacy hostname
+65539 | VPN | N/A | [This.I-D] | VPN resolution
+65540 | GNS2DNS | N/A | [This.I-D] | Delegation to DNS
+65541 | BOX | N/A | [This.I-D] | Boxed record
</pre>
</div>
<figcaption><a href="#figure-18" class="selfRef">Figure
18</a></figcaption></figure>
@@ -2969,6 +3031,9 @@ bEclYC3aE2+fjSDDfRpdnv3gGHMckMceVbgymHZDlfA=
<dt id="GNS">[GNS]</dt>
<dd>
<span class="refAuthor">Wachs, M.</span><span class="refAuthor">,
Schanzenbach, M.</span><span class="refAuthor">, and C. Grothoff</span>, <span
class="refTitle">"A Censorship-Resistant, Privacy-Enhancing and Fully
Decentralized Name System"</span>, <time datetime="2014">2014</time>,
<span><<a
href="https://doi.org/10.1007/978-3-319-12280-9_9";>https://doi.org/10.1007/978-3-319-12280-9_9</a>></span>.
</dd>
+<dt id="R5N">[R5N]</dt>
+<dd>
+<span class="refAuthor">Evans, N. S.</span><span class="refAuthor"> and C.
Grothoff</span>, <span class="refTitle">"R5N: Randomized recursive routing for
restricted-route networks"</span>, <time datetime="2011">2011</time>,
<span><<a
href="https://doi.org/10.1109/ICNSS.2011.6060022";>https://doi.org/10.1109/ICNSS.2011.6060022</a>></span>.
</dd>
<dt id="Argon2">[Argon2]</dt>
<dd>
<span class="refAuthor">Biryukov, A.</span><span class="refAuthor">, Dinu,
D.</span><span class="refAuthor">, Khovratovich, D.</span><span
class="refAuthor">, and S. Josefsson</span>, <span class="refTitle">"The
memory-hard Argon2 password hash and proof-of-work function"</span>, <time
datetime="2020-03">March 2020</time>, <span><<a
href="https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/";>https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/</a>></span>.
</dd>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index c1cf401..e0e1d67 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -87,15 +87,15 @@ Table of Contents
7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 19
8. Determining the Root Zone and Zone Governance . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
- 9.1. Abuse mitigation . . . . . . . . . . . . . . . . . . . . 25
- 9.2. Zone key management . . . . . . . . . . . . . . . . . . . 25
- 9.3. Root zone management . . . . . . . . . . . . . . . . . . 25
- 9.4. Impact of underlying DHT . . . . . . . . . . . . . . . . 25
- 9.5. Revocations . . . . . . . . . . . . . . . . . . . . . . . 26
- 10. GANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
- 11. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 27
- 12. Normative References . . . . . . . . . . . . . . . . . . . . 29
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
+ 9.1. Cryptography . . . . . . . . . . . . . . . . . . . . . . 25
+ 9.2. Abuse mitigation . . . . . . . . . . . . . . . . . . . . 26
+ 9.3. Zone management . . . . . . . . . . . . . . . . . . . . . 26
+ 9.4. Impact of underlying DHT . . . . . . . . . . . . . . . . 26
+ 9.5. Revocations . . . . . . . . . . . . . . . . . . . . . . . 27
+ 10. GANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
+ 11. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 28
+ 12. Normative References . . . . . . . . . . . . . . . . . . . . 30
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
@@ -207,16 +207,16 @@ Internet-Draft The GNU Name System
November 2019
A GNS resource record holds the data of a specific record in a zone.
The resource record format is defined as follows:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / /
- / /
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA SIZE | TYPE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | FLAGS | DATA /
+ +-----+-----+-----+-----+ /
+ / /
+ / /
@@ -254,10 +254,10 @@ Internet-Draft The GNU Name System
November 2019
illustrates the flag distribution in the 32-bit flag value of a
resource record:
- ... 5 4 3 2 1 0
- ------+--------+--------+--------+--------+--------+
- / ... | SHADOW | EXPREL | SUPPL | PRIVATE| / |
- ------+--------+--------+--------+--------+--------+
+ ... 5 4 3 2 1 0
+ ------+--------+--------+--------+--------+--------+
+ / ... | SHADOW | EXPREL | SUPPL | PRIVATE| / |
+ ------+--------+--------+--------+--------+--------+
Figure 2
@@ -314,13 +314,13 @@ Internet-Draft The GNU Name System
November 2019
label. No other records are allowed. A PKEY DATA entry has the
following format:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 3
@@ -346,18 +346,18 @@ Internet-Draft The GNU Name System
November 2019
format defined in [RFC1034] for DNS names. A GNS2DNS DATA entry has
the following format:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DNS NAME |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DNS SERVER NAME |
- / /
- / /
- | |
- +-----------------------------------------------+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DNS NAME |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DNS SERVER NAME |
+ / /
+ / /
+ | |
+ +-----------------------------------------------+
Figure 4
@@ -379,13 +379,13 @@ Internet-Draft The GNU Name System
November 2019
expected to be found together in a single resource record with an
IPv4 or IPv6 address. A LEHO DATA entry has the following format:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | LEGACY HOSTNAME |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | LEGACY HOSTNAME |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
@@ -417,13 +417,13 @@ Internet-Draft The GNU Name System
November 2019
non-supplemental NICK records. A NICK DATA entry has the following
format:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | NICKNAME |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | NICKNAME |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 6
@@ -454,15 +454,15 @@ Internet-Draft The GNU Name System
November 2019
(PROTO) 6 (tcp) and record TYPE "TLSA". For reference, see also
[RFC2782]. A BOX DATA entry has the following format:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PROTO | SVC | TYPE |
- +-----------+-----------------------------------+
- | RECORD DATA |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PROTO | SVC | TYPE |
+ +-----------+-----------------------------------+
+ | RECORD DATA |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 7
@@ -484,19 +484,19 @@ Internet-Draft The GNU Name System
November 2019
A VPN DATA entry has the following format:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | HOSTING PEER PUBLIC KEY |
- | (256 bits) |
- | |
- | |
- +-----------+-----------------------------------+
- | PROTO | SERVICE NAME |
- +-----------+ +
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | HOSTING PEER PUBLIC KEY |
+ | (256 bits) |
+ | |
+ | |
+ +-----------+-----------------------------------+
+ | PROTO | SERVICE NAME |
+ +-----------+ +
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
@@ -535,11 +535,11 @@ Internet-Draft The GNU Name System
November 2019
Given a label, the DHT key "q" is derived as follows:
- PRK_h := HKDF-Extract ("key-derivation", zk)
- h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
- d_h := h * d mod L
- zk_h := h mod L * zk
- q := SHA512 (zk_h)
+ PRK_h := HKDF-Extract ("key-derivation", zk)
+ h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
+ d_h := h * d mod L
+ zk_h := h mod L * zk
+ q := SHA512 (zk_h)
We use a hash-based key derivation function (HKDF) as defined in
[RFC5869]. We use HMAC-SHA512 for the extraction phase and HMAC-
@@ -618,30 +618,30 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 11]
Internet-Draft The GNU Name System November 2019
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIGNATURE |
- | |
- | |
- | |
- | |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIZE | PURPOSE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | BDATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | SIGNATURE |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | SIZE | PURPOSE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | BDATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 9
@@ -694,29 +694,29 @@ Internet-Draft The GNU Name System
November 2019
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
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | RR COUNT | EXPIRA- /
- +-----+-----+-----+-----+-----+-----+-----+-----+
- / -TION | DATA SIZE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TYPE | FLAGS |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / +-----------------------/
- / | /
- +-----------------------+ /
- / PADDING /
- / /
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | RR COUNT | EXPIRA- /
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ / -TION | DATA SIZE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TYPE | FLAGS |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA SIZE | TYPE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | FLAGS | DATA /
+ +-----+-----+-----+-----+ /
+ / +-----------------------/
+ / | /
+ +-----------------------+ /
+ / PADDING /
+ / /
Figure 10
@@ -749,10 +749,10 @@ Internet-Draft The GNU Name System
November 2019
records block payload, the key material "K" and initialization vector
"IV" for the symmetric cipher are derived as follows:
- 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)
+ 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)
HKDF is a hash-based key derivation function as defined in [RFC5869].
Specifically, HMAC-SHA512 is used for the extraction phase and HMAC-
@@ -762,18 +762,18 @@ Internet-Draft The GNU Name System
November 2019
"K" into a 256-bit AES [RFC3826] key and a 256-bit TWOFISH [TWOFISH]
key:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 11
@@ -789,14 +789,14 @@ Internet-Draft The GNU Name System
November 2019
Similarly, we divide "IV" into a 128-bit initialization vector and a
128-bit initialization vector:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES IV |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH IV |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES IV |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH IV |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 12
@@ -804,10 +804,10 @@ Internet-Draft The GNU Name System
November 2019
chained symmetric cipher. Both ciphers are used in Cipher FeedBack
(CFB) mode [RFC3826].
- RDATA := AES(K[0:31], IV[0:15],
- TWOFISH(K[32:63], IV[16:31], BDATA))
- BDATA := TWOFISH(K[32:63], IV[16:31],
- AES(K[0:31], IV[0:15], RDATA))
+ RDATA := AES(K[0:31], IV[0:15],
+ TWOFISH(K[32:63], IV[16:31], BDATA))
+ BDATA := TWOFISH(K[32:63], IV[16:31],
+ AES(K[0:31], IV[0:15], RDATA))
5. Internationalization and Character Encoding
@@ -1023,10 +1023,10 @@ Internet-Draft The GNU Name System
November 2019
record allows the client to match the record to the authoritative
zone. Consider the following example:
- Query: alice.doe (type=A)
- Result:
- A: 1.2.3.4
- NICK: eve
+ Query: alice.doe (type=A)
+ Result:
+ A: 1.2.3.4
+ NICK: eve
Figure 13
@@ -1037,10 +1037,10 @@ Internet-Draft The GNU Name System
November 2019
wants to be referred to as "eve". In contrast, consider the
following:
- Query: alice.doe (type=A)
- Result:
- A: 1.2.3.4
- NICK: john (Supplemental)
+ Query: alice.doe (type=A)
+ Result:
+ A: 1.2.3.4
+ NICK: john (Supplemental)
Figure 14
@@ -1077,29 +1077,29 @@ Internet-Draft The GNU Name System
November 2019
Derivation Function as defined in [Argon2]. For the PoW calculations
the algorithm is instantiated with the following parameters:
- S := "gnunet-revocation-proof-of-work" /* Salt */
- t := 3 /* Iterations */
- m := 1024 /* Memory size, 1 MiB */
- T := 64 /* Tag (=output) length in bytes */
- p := 1 /* Parallelization parameter */
- v := 0x13 /* Version */
- y := 0 /* Type (Argon2d) */
- X, K is unused
+ S := "gnunet-revocation-proof-of-work" /* Salt */
+ t := 3 /* Iterations */
+ m := 1024 /* Memory size, 1 MiB */
+ T := 64 /* Tag (=output) length in bytes */
+ p := 1 /* Parallelization parameter */
+ v := 0x13 /* Version */
+ y := 0 /* Type (Argon2d) */
+ X, K is unused
The following is the message string "P" on which the PoW is
calculated:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | POW |
- +-----------------------------------------------+
- | TIMESTAMP |
- +-----------------------------------------------+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | POW |
+ +-----------------------------------------------+
+ | TIMESTAMP |
+ +-----------------------------------------------+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 15
@@ -1178,32 +1178,32 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 21]
Internet-Draft The GNU Name System November 2019
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TIMESTAMP |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TTL |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | POW_0 |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | ... |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | POW_Z-1 |
- +-----------------------------------------------+
- | SIGNATURE |
- | |
- | |
- | |
- | |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TIMESTAMP |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TTL |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | POW_0 |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | ... |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | POW_Z-1 |
+ +-----------------------------------------------+
+ | SIGNATURE |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 16
@@ -1245,17 +1245,17 @@ Internet-Draft The GNU Name System
November 2019
conceptually prefixed to the public key. The pseudo header includes
the key length and signature purpose:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIZE (0x30) | PURPOSE (0x03) |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TIMESTAMP |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | SIZE (0x30) | PURPOSE (0x03) |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TIMESTAMP |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 17
@@ -1324,9 +1324,9 @@ Internet-Draft The GNU Name System
November 2019
Base32-encoded public zone key "zk", the root zone of the resolution
process is implicitly given by the name:
- Example name: www.example.<Base32(zk)>
- => Root zone: zk
- => Name to resolve from root zone: www.example
+ Example name: www.example.<Base32(zk)>
+ => Root zone: zk
+ => Name to resolve from root zone: www.example
In GNS, users MAY own and manage their own zones. Each local zone
SHOULD be associated with a single GNS label, but users MAY choose to
@@ -1346,14 +1346,14 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 24]
Internet-Draft The GNU Name System November 2019
- Example name: www.example.gnu
- Local zones:
- fr = (d0,zk0)
- gnu = (d1,zk1)
- com = (d2,zk2)
- ...
- => Entry zone: zk1
- => Name to resolve from entry zone: www.example
+ Example name: www.example.gnu
+ Local zones:
+ fr = (d0,zk0)
+ gnu = (d1,zk1)
+ com = (d2,zk2)
+ ...
+ => Entry zone: zk1
+ => Name to resolve from entry zone: www.example
Finally, additional "suffix to zone" mappings MAY be configured.
Suffix to zone key mappings SHOULD be configurable through a local
@@ -1365,45 +1365,108 @@ 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.
- Example name: www.example.gnu
- Local suffix mappings:
- gnu = zk0
- example.gnu = zk1
- example.com = zk2
- ...
- => Entry zone: zk1
- => Name to resolve from entry zone: www
+ Example name: www.example.gnu
+ Local suffix mappings:
+ gnu = zk0
+ example.gnu = zk1
+ example.com = zk2
+ ...
+ => Entry zone: zk1
+ => Name to resolve from entry zone: www
9. Security Considerations
-9.1. Abuse mitigation
+9.1. Cryptography
- DNS abuse: Squatting, takedowns, homographs.
+ The security of cryptographic systems depends on both the strength of
+ the cryptographic algorithms chosen and the strength of the keys used
+ with those algorithms. The security also depends on the engineering
+ of the protocol used by the system to ensure that there are no non-
+ cryptographic ways to bypass the security of the overall system.
-9.2. Zone key management
+ This document concerns itself with the selection of cryptographic
+ algorithms for use in GNS. The algorithms identified in this
+ document are not known to be broken (in the cryptographic sense) at
+ the current time, and cryptographic research so far leads us to
+ believe that they are likely to remain secure into the foreseeable
+ future. However, this isn't necessarily forever, and it is expected
+ that new revisions of this document will be issued from time to time
+ to reflect the current best practices in this area.
- Users need to manage and protect zone keys.
-9.3. Root zone management
- Users must manage local root zone (availability).
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 25]
+
+Internet-Draft The GNU Name System November 2019
+
+
+9.2. Abuse mitigation
+
+ GNS names are UTF-8 strings. Consequently, GNS faces similar issues
+ with respect to name spoofing as DNS does for internationalized
+ domain names. In DNS, attackers may register similar sounding or
+ looking names (see above) in order to execute phishing attacks. GNS
+ zone administrators must take into account this attack vector and
+ incorporate rules in order to mitigate it.
+
+ Further, DNS can be used to combat illegal content on the internet by
+ having the respective domains seized by authorities. However, the
+ same mechanisms can also be abused in order to impose state
+ censorship, which ist one of the motivations behind GNS. Hence, such
+ a seizure is, by design, difficult to impossible in GNS.
+
+9.3. Zone management
+
+ In GNS, zone administrators need to manage and protect their zone
+ keys. Once a zone key is lost it cannot be recovered. Once it is
+ compromised it cannot be revoked (unless a revocation was pre-
+ calculated and is still available). Zone administrators, and for GNS
+ this includes end-users, are required to responsibly and dilligently
+ protect their cryptographic keys.
+
+ Similarly, users are required to manage their local root zone. In
+ order to ensure integrity and availability or names, users must
+ ensure that their local root zone information is not compromised or
+ outdated. It can be expected that the processing of zone revocations
+ and an initial root zone is provided with a GNS client implementation
+ ("drop shipping"). Extension and customization of the zone is at the
+ full discretion of the user.
9.4. Impact of underlying DHT
- Is significant.
+ This document does not specifiy the properties of the underlying
+ distributed hash table (DHT) which is required by any GNS
+ implementation. For implementors, it is important to note that the
+ properties of the DHT are directly inherited by the GNS
+ implementation. This includes both security as well as other non-
+ functional properties such as scalability and performance.
+ Implementors should take great care when selecting or implementing a
+ DHT for use in a GNS implementation. DHTs with string security and
+ performance guarantees exist [R5N]. It should also be taken into
+ consideration that GNS implementations which build upon different DHT
+ overlays are unlikely to be interoperable with each other.
-Schanzenbach, et al. Expires 13 May 2020 [Page 25]
+Schanzenbach, et al. Expires 13 May 2020 [Page 26]
Internet-Draft The GNU Name System November 2019
9.5. Revocations
+ Zone administrators are advised to pre-generate zone revocations and
+ securely store the revocation information in case the zone key is
+ lost, compromised or replaced in the furture. Pre-calculated
+ revocations may become invalid due to expirations or protocol changes
+ such as epoch adjustments. Conseuquently, implementors and users
+ must make precautions in order to manage revocations accordingly.
+
Revocation payloads do NOT include a 'new' key for key replacement.
In inclusion of such a key would have two major disadvantages:
@@ -1444,28 +1507,25 @@ Internet-Draft The GNU Name System
November 2019
* 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]. GANA is requested to populate
- this registry as follows:
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 26]
+Schanzenbach, et al. Expires 13 May 2020 [Page 27]
Internet-Draft The GNU Name System November 2019
- Number | Name | 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]
+ The registration policy for this sub-registry is "First Come First
+ Served", as described in [RFC8126]. GANA is requested to populate
+ this registry as follows:
+
+ Number | Name | Contact | References | Description
+ -------+---------+---------+------------+-------------------------
+ 65536 | PKEY | N/A | [This.I-D] | GNS zone delegation
+ 65537 | NICK | N/A | [This.I-D] | GNS zone nickname
+ 65538 | LEHO | N/A | [This.I-D] | GNS legacy hostname
+ 65539 | VPN | N/A | [This.I-D] | VPN resolution
+ 65540 | GNS2DNS | N/A | [This.I-D] | Delegation to DNS
+ 65541 | BOX | N/A | [This.I-D] | Boxed record
Figure 18
@@ -1505,11 +1565,7 @@ Internet-Draft The GNU Name System
November 2019
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 27]
+Schanzenbach, et al. Expires 13 May 2020 [Page 28]
Internet-Draft The GNU Name System November 2019
@@ -1565,7 +1621,7 @@ Internet-Draft The GNU Name System
November 2019
-Schanzenbach, et al. Expires 13 May 2020 [Page 28]
+Schanzenbach, et al. Expires 13 May 2020 [Page 29]
Internet-Draft The GNU Name System November 2019
@@ -1621,7 +1677,7 @@ Internet-Draft The GNU Name System
November 2019
-Schanzenbach, et al. Expires 13 May 2020 [Page 29]
+Schanzenbach, et al. Expires 13 May 2020 [Page 30]
Internet-Draft The GNU Name System November 2019
@@ -1672,16 +1728,21 @@ Internet-Draft The GNU Name System
November 2019
Decentralized Name System", 2014,
<https://doi.org/10.1007/978-3-319-12280-9_9>.
- [Argon2] Biryukov, A., Dinu, D., Khovratovich, D., and S.
- Josefsson, "The memory-hard Argon2 password hash and
+ [R5N] Evans, N. S. and C. Grothoff, "R5N: Randomized recursive
-Schanzenbach, et al. Expires 13 May 2020 [Page 30]
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 31]
Internet-Draft The GNU Name System November 2019
+ routing for restricted-route networks", 2011,
+ <https://doi.org/10.1109/ICNSS.2011.6060022>.
+
+ [Argon2] Biryukov, A., Dinu, D., Khovratovich, D., and S.
+ Josefsson, "The memory-hard Argon2 password hash and
proof-of-work function", March 2020,
<https://datatracker.ietf.org/doc/draft-irtf-cfrg-
argon2/>.
@@ -1728,9 +1789,4 @@ Authors' Addresses
-
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 31]
+Schanzenbach, et al. Expires 13 May 2020 [Page 32]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index c4598b3..d6f98d8 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -185,16 +185,16 @@
</t>
<figure anchor="figure_gnsrecord">
<artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / /
- / /
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EXPIRATION |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| DATA SIZE | TYPE |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| FLAGS | DATA /
++-----+-----+-----+-----+ /
+/ /
+/ /
]]></artwork>
<!-- <postamble>which is a very simple example.</postamble>-->
</figure>
@@ -238,10 +238,10 @@
resource record:</t>
<figure anchor="figure_flag">
<artwork name="" type="" align="left" alt=""><![CDATA[
- ... 5 4 3 2 1 0
- ------+--------+--------+--------+--------+--------+
- / ... | SHADOW | EXPREL | SUPPL | PRIVATE| / |
- ------+--------+--------+--------+--------+--------+
+... 5 4 3 2 1 0
+------+--------+--------+--------+--------+--------+
+/ ... | SHADOW | EXPREL | SUPPL | PRIVATE| / |
+------+--------+--------+--------+--------+--------+
]]></artwork>
<!-- <postamble>which is a very simple example.</postamble>-->
</figure>
@@ -301,13 +301,13 @@
records are allowed. A PKEY DATA entry has the following format:</t>
<figure anchor="figure_pkeyrecord">
<artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| PUBLIC KEY |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
<!-- <postamble>which is a very simple example.</postamble>-->
</figure>
@@ -330,18 +330,18 @@
A GNS2DNS DATA entry has the following format:</t>
<figure anchor="figure_gns2dnsrecord">
<artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DNS NAME |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DNS SERVER NAME |
- / /
- / /
- | |
- +-----------------------------------------------+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| DNS NAME |
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| DNS SERVER NAME |
+/ /
+/ /
+| |
++-----------------------------------------------+
]]></artwork>
<!-- <postamble>which is a very simple example.</postamble>-->
</figure>
@@ -375,13 +375,13 @@
A LEHO DATA entry has the following format:</t>
<figure anchor="figure_lehorecord">
<artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | LEGACY HOSTNAME |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| LEGACY HOSTNAME |
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
<!-- <postamble>which is a very simple example.</postamble>-->
</figure>
@@ -416,13 +416,13 @@
</t>
<figure anchor="figure_nickrecord">
<artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | NICKNAME |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| NICKNAME |
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
<!-- <postamble>which is a very simple example.</postamble>-->
</figure>
@@ -455,15 +455,15 @@
</t>
<figure anchor="figure_boxrecord">
<artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PROTO | SVC | TYPE |
- +-----------+-----------------------------------+
- | RECORD DATA |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| PROTO | SVC | TYPE |
++-----------+-----------------------------------+
+| RECORD DATA |
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
<!-- <postamble>which is a very simple example.</postamble>-->
</figure>
@@ -497,19 +497,19 @@
A VPN DATA entry has the following format:</t>
<figure anchor="figure_vpnrecord">
<artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | HOSTING PEER PUBLIC KEY |
- | (256 bits) |
- | |
- | |
- +-----------+-----------------------------------+
- | PROTO | SERVICE NAME |
- +-----------+ +
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| HOSTING PEER PUBLIC KEY |
+| (256 bits) |
+| |
+| |
++-----------+-----------------------------------+
+| PROTO | SERVICE NAME |
++-----------+ +
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
<!-- <postamble>which is a very simple example.</postamble>-->
</figure>
@@ -553,11 +553,11 @@
Given a label, the DHT key "q" is derived as follows:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
- PRK_h := HKDF-Extract ("key-derivation", zk)
- h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
- d_h := h * d mod L
- zk_h := h mod L * zk
- q := SHA512 (zk_h)
+PRK_h := HKDF-Extract ("key-derivation", zk)
+h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
+d_h := h * d mod L
+zk_h := h mod L * zk
+q := SHA512 (zk_h)
]]></artwork>
<t>
We use a hash-based key derivation function (HKDF) as defined in
@@ -627,30 +627,30 @@
</t>
<figure anchor="figure_record_block">
<artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIGNATURE |
- | |
- | |
- | |
- | |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIZE | PURPOSE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | BDATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIGNATURE |
+| |
+| |
+| |
+| |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| PUBLIC KEY |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIZE | PURPOSE |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EXPIRATION |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| BDATA /
+/ /
+/ |
++-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
<t>where:</t>
@@ -714,29 +714,29 @@
</t>
<figure anchor="figure_rdata">
<artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | RR COUNT | EXPIRA- /
- +-----+-----+-----+-----+-----+-----+-----+-----+
- / -TION | DATA SIZE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TYPE | FLAGS |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / +-----------------------/
- / | /
- +-----------------------+ /
- / PADDING /
- / /
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| RR COUNT | EXPIRA- /
++-----+-----+-----+-----+-----+-----+-----+-----+
+/ -TION | DATA SIZE |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| TYPE | FLAGS |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| DATA /
+/ /
+/ |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EXPIRATION |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| DATA SIZE | TYPE |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| FLAGS | DATA /
++-----+-----+-----+-----+ /
+/ +-----------------------/
+/ | /
++-----------------------+ /
+/ PADDING /
+/ /
]]></artwork>
<!-- <postamble>which is a very simple example.</postamble>-->
</figure>
@@ -778,10 +778,10 @@
IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
-->
<artwork name="" type="" align="left" alt=""><![CDATA[
- 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)
+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)
]]></artwork>
<t>
HKDF is a hash-based key derivation function as defined in
@@ -795,18 +795,18 @@
</t>
<figure anchor="figure_hkdf_keys">
<artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| AES KEY |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| TWOFISH KEY |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
<!-- <postamble>which is a very simple example.</postamble>-->
</figure>
@@ -816,14 +816,14 @@
</t>
<figure anchor="figure_hkdf_ivs">
<artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES IV |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH IV |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| AES IV |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| TWOFISH IV |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
<!-- <postamble>which is a very simple example.</postamble>-->
</figure>
@@ -834,10 +834,10 @@
Cipher FeedBack (CFB) mode <xref target="RFC3826" />.
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
- RDATA := AES(K[0:31], IV[0:15],
- TWOFISH(K[32:63], IV[16:31], BDATA))
- BDATA := TWOFISH(K[32:63], IV[16:31],
- AES(K[0:31], IV[0:15], RDATA))
+RDATA := AES(K[0:31], IV[0:15],
+ TWOFISH(K[32:63], IV[16:31], BDATA))
+BDATA := TWOFISH(K[32:63], IV[16:31],
+ AES(K[0:31], IV[0:15], RDATA))
]]></artwork>
</section>
</section>
@@ -1085,10 +1085,10 @@
</t>
<figure>
<artwork name="" type="" align="left" alt=""><![CDATA[
- Query: alice.doe (type=A)
- Result:
- A: 1.2.3.4
- NICK: eve
+Query: alice.doe (type=A)
+Result:
+A: 1.2.3.4
+NICK: eve
]]></artwork>
</figure>
<t>
@@ -1101,10 +1101,10 @@
</t>
<figure>
<artwork name="" type="" align="left" alt=""><![CDATA[
- Query: alice.doe (type=A)
- Result:
- A: 1.2.3.4
- NICK: john (Supplemental)
+Query: alice.doe (type=A)
+Result:
+A: 1.2.3.4
+NICK: john (Supplemental)
]]></artwork>
</figure>
<t>
@@ -1145,14 +1145,14 @@
following parameters:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
- S := "gnunet-revocation-proof-of-work" /* Salt */
- t := 3 /* Iterations */
- m := 1024 /* Memory size, 1 MiB */
- T := 64 /* Tag (=output) length in bytes */
- p := 1 /* Parallelization parameter */
- v := 0x13 /* Version */
- y := 0 /* Type (Argon2d) */
- X, K is unused
+S := "gnunet-revocation-proof-of-work" /* Salt */
+t := 3 /* Iterations */
+m := 1024 /* Memory size, 1 MiB */
+T := 64 /* Tag (=output) length in bytes */
+p := 1 /* Parallelization parameter */
+v := 0x13 /* Version */
+y := 0 /* Type (Argon2d) */
+X, K is unused
]]></artwork>
<t>
The following is the message string "P" on which the PoW is
@@ -1160,17 +1160,17 @@
</t>
<figure anchor="figure_revocation">
<artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | POW |
- +-----------------------------------------------+
- | TIMESTAMP |
- +-----------------------------------------------+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| POW |
++-----------------------------------------------+
+| TIMESTAMP |
++-----------------------------------------------+
+| PUBLIC KEY |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
<t>where:</t>
@@ -1228,32 +1228,32 @@
</t>
<figure anchor="figure_revocationdata">
<artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TIMESTAMP |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TTL |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | POW_0 |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | ... |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | POW_Z-1 |
- +-----------------------------------------------+
- | SIGNATURE |
- | |
- | |
- | |
- | |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| TIMESTAMP |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| TTL |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| POW_0 |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| ... |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| POW_Z-1 |
++-----------------------------------------------+
+| SIGNATURE |
+| |
+| |
+| |
+| |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| PUBLIC KEY |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
<t>where:</t>
@@ -1301,17 +1301,17 @@
</t>
<figure anchor="figure_revsigwithpseudo">
<artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIZE (0x30) | PURPOSE (0x03) |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TIMESTAMP |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIZE (0x30) | PURPOSE (0x03) |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| PUBLIC KEY |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| TIMESTAMP |
++-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
<t>where:</t>
@@ -1383,9 +1383,9 @@
by the name:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
- Example name: www.example.<Base32(zk)>
- => Root zone: zk
- => Name to resolve from root zone: www.example
+Example name: www.example.<Base32(zk)>
+=> Root zone: zk
+=> Name to resolve from root zone: www.example
]]></artwork>
<t>
In GNS, users MAY own and manage their own zones.
@@ -1397,14 +1397,14 @@
resolution SHOULD start from the respective local zone:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
- Example name: www.example.gnu
- Local zones:
- fr = (d0,zk0)
- gnu = (d1,zk1)
- com = (d2,zk2)
- ...
- => Entry zone: zk1
- => Name to resolve from entry zone: www.example
+Example name: www.example.gnu
+Local zones:
+fr = (d0,zk0)
+gnu = (d1,zk1)
+com = (d2,zk2)
+...
+=> Entry zone: zk1
+=> Name to resolve from entry zone: www.example
]]></artwork>
<t>
Finally, additional "suffix to zone" mappings MAY be configured.
@@ -1418,44 +1418,110 @@
for the same suffix, the locally managed zone MUST have priority.
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
- Example name: www.example.gnu
- Local suffix mappings:
- gnu = zk0
- example.gnu = zk1
- example.com = zk2
- ...
- => Entry zone: zk1
- => Name to resolve from entry zone: www
+Example name: www.example.gnu
+Local suffix mappings:
+gnu = zk0
+example.gnu = zk1
+example.com = zk2
+...
+=> Entry zone: zk1
+=> Name to resolve from entry zone: www
]]></artwork>
</section>
<section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name>
+ <section anchor="security_crypto" numbered="true" toc="default">
+ <name>Cryptography</name>
+ <t>
+ The security of cryptographic systems depends on both the strength
of
+ the cryptographic algorithms chosen and the strength of the keys
used
+ with those algorithms. The security also depends on the engineering
+ of the protocol used by the system to ensure that there are no
+ non-cryptographic ways to bypass the security of the overall system.
+ </t>
+ <t>
+ This document concerns itself with the selection of cryptographic
+ algorithms for use in GNS.
+ The algorithms identified in this document are not known to be
+ broken (in the cryptographic sense) at the current time, and
+ cryptographic research so far leads us to believe that they are
+ likely to remain secure into the foreseeable future. However, this
+ isn't necessarily forever, and it is expected that new revisions of
+ this document will be issued from time to time to reflect the
current
+ best practices in this area.
+ </t>
+ </section>
<section anchor="security_abuse" numbered="true" toc="default">
<name>Abuse mitigation</name>
<t>
- DNS abuse: Squatting, takedowns, homographs.
+ GNS names are UTF-8 strings. Consequently, GNS faces similar issues
+ with respect to name spoofing as DNS does for internationalized
+ domain names.
+ In DNS, attackers may register similar sounding or looking
+ names (see above) in order to execute phishing attacks.
+ GNS zone administrators must take into account this attack vector
and
+ incorporate rules in order to mitigate it.
+ </t>
+ <t>
+ Further, DNS can be used to combat illegal content on the internet
+ by having the respective domains seized by authorities.
+ However, the same mechanisms can also be abused in order to impose
+ state censorship, which ist one of the motivations behind GNS.
+ Hence, such a seizure is, by design, difficult to impossible in GNS.
</t>
</section>
<section anchor="security_keymanagement" numbered="true" toc="default">
- <name>Zone key management</name>
+ <name>Zone management</name>
<t>
- Users need to manage and protect zone keys.
+ In GNS, zone administrators need to manage and protect their zone
+ keys. Once a zone key is lost it cannot be recovered. Once it is
+ compromised it cannot be revoked (unless a revocation was
+ pre-calculated and is still available).
+ Zone administrators, and for GNS this includes end-users, are
+ required to responsibly and dilligently protect their cryptographic
+ keys.
</t>
- </section>
- <section anchor="security_root" numbered="true" toc="default">
- <name>Root zone management</name>
<t>
- Users must manage local root zone (availability).
+ Similarly, users are required to manage their local root zone.
+ In order to ensure integrity and availability or names, users must
+ ensure that their local root zone information is not compromised or
+ outdated.
+ It can be expected that the processing of zone revocations and an
+ initial root zone is provided with a GNS client implementation
+ ("drop shipping").
+ Extension and customization of the zone is at the full discretion of
+ the user.
</t>
</section>
<section anchor="security_dht" numbered="true" toc="default">
<name>Impact of underlying DHT</name>
<t>
- Is significant.
+ This document does not specifiy the properties of the underlying
+ distributed hash table (DHT) which is required by any GNS
+ implementation. For implementors, it is important to note that
+ the properties of the DHT are directly inherited by the
+ GNS implementation. This includes both security as well as
+ other non-functional properties such as scalability and performance.
+ Implementors should take great care when selecting or implementing
+ a DHT for use in a GNS implementation.
+ DHTs with string security and performance guarantees exist
+ <xref target="R5N"/>.
+ It should also be taken into consideration that GNS implementations
+ which build upon different DHT overlays are unlikely to be
+ interoperable with each other.
</t>
</section>
<section anchor="security_rev" numbered="true" toc="default">
<name>Revocations</name>
+ <t>
+ Zone administrators are advised to pre-generate zone revocations
+ and securely store the revocation information in case the zone
+ key is lost, compromised or replaced in the furture.
+ Pre-calculated revocations may become invalid due to expirations
+ or protocol changes such as epoch adjustments.
+ Conseuquently, implementors and users must make precautions in order
+ to manage revocations accordingly.
+ </t>
<t>
Revocation payloads do NOT include a 'new' key for key replacement.
In inclusion of such a key would have two major disadvantages:
@@ -1503,18 +1569,17 @@ The registry shall record for each entry:
The registration policy for this sub-registry is "First Come First
Served", as described in <xref target="RFC8126"/>.
GANA is requested to populate this registry as follows:
- <!-- FIXME: insert comments... -->
</t>
<figure anchor="figure_rrtypenums">
<artwork name="" type="" align="left" alt=""><![CDATA[
- Number | Name | 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]
+Number | Name | Contact | References | Description
+-------+---------+---------+------------+-------------------------
+65536 | PKEY | N/A | [This.I-D] | GNS zone delegation
+65537 | NICK | N/A | [This.I-D] | GNS zone nickname
+65538 | LEHO | N/A | [This.I-D] | GNS legacy hostname
+65539 | VPN | N/A | [This.I-D] | VPN resolution
+65540 | GNS2DNS | N/A | [This.I-D] | Delegation to DNS
+65541 | BOX | N/A | [This.I-D] | Boxed record
]]></artwork>
<!-- <postamble>which is a very simple example.</postamble>-->
</figure>
@@ -1650,6 +1715,21 @@ bEclYC3aE2+fjSDDfRpdnv3gGHMckMceVbgymHZDlfA=
<date year="2014"/>
</front>
</reference>
+ <reference anchor="R5N"
target="https://doi.org/10.1109/ICNSS.2011.6060022";>
+ <front>
+ <title>R5N: Randomized recursive routing for restricted-route
networks</title>
+ <author initials="N. S." surname="Evans" fullname="Nathan S. Evans">
+ <organization>Technische Universität München</organization>
+ </author>
+
+ <author initials="C." surname="Grothoff"
+ fullname="Christian Grothoff">
+ <organization>Technische Universität München</organization>
+ </author>
+ <date year="2011"/>
+ </front>
+ </reference>
+
<reference anchor="Argon2"
target="https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/";>
<front>
--
To stop receiving notification emails like this one, please contact
address@hidden.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: security considerations,
gnunet <=