[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] [lsd0001] branch master updated: update crypto references;
|
From: |
gnunet |
|
Subject: |
[GNUnet-SVN] [lsd0001] branch master updated: update crypto references; minor clarifications from bfix |
|
Date: |
Fri, 20 Sep 2019 15:08:50 +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 4b3b969 update crypto references; minor clarifications from bfix
4b3b969 is described below
commit 4b3b969beacad7a85080d142caffe58bef66be38
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Fri Sep 20 15:05:48 2019 +0200
update crypto references; minor clarifications from bfix
---
draft-schanzen-gns.html | 613 ++++++++++++++-------------
draft-schanzen-gns.txt | 398 ++++++++++--------
draft-schanzen-gns.xml | 1047 +++++++++++++++++++++++++----------------------
3 files changed, 1118 insertions(+), 940 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 8f7f3c4..7b55b46 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -5,9 +5,11 @@
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>
- The GNU Name System Specification
+ The GNU Name System Specification
</title>
<meta content="Martin Schanzenbach" name="author">
+<meta content="Christian Grothoff" name="author">
+<meta content="Bernd Fix" name="author">
<meta content="
This document contains the GNU Name System (GNS) technical
specification.
" name="description">
@@ -978,7 +980,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<td class="right">July 2019</td>
</tr></thead>
<tfoot><tr>
-<td class="left">Schanzenbach</td>
+<td class="left">Schanzenbach, et al.</td>
<td class="center">Expires 24 January 2020</td>
<td class="right">[Page]</td>
</tr></tfoot>
@@ -997,17 +999,25 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<dd class="intended-status">Informational</dd>
<dt class="label-expires">Expires:</dt>
<dd class="expires"><time datetime="2020-01-24">24 January 2020</time></dd>
-<dt class="label-authors">Author:</dt>
+<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
- <div class="author-name">M.S. Schanzenbach</div>
+ <div class="author-name">M. Schanzenbach</div>
+<div class="org">GNUnet e.V.</div>
+</div>
+<div class="author">
+ <div class="author-name">C. Grothhoff</div>
+<div class="org">GNUnet e.V.</div>
+</div>
+<div class="author">
+ <div class="author-name">B. Fix</div>
<div class="org">GNUnet e.V.</div>
</div>
</dd>
</dl>
</div>
<h1 id="title">
- The GNU Name System Specification
+ The GNU Name System Specification
</h1>
<section id="section-abstract">
<h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
@@ -1082,10 +1092,13 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<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-resource-records-block"
class="xref">Resource records block</a><a
href="#section-boilerplate.3-1.4.2.1.1" class="pilcrow">¶</a></p>
+ <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>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.4.2.2">
- <p id="section-boilerplate.3-1.4.2.2.1"><a href="#section-4.2"
class="xref">4.2</a>. <a href="#name-block-data-encryption" class="xref">Block
data encryption</a><a href="#section-boilerplate.3-1.4.2.2.1"
class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.4.2.2.1"><a href="#section-4.2"
class="xref">4.2</a>. <a href="#name-resource-records-block"
class="xref">Resource records block</a><a
href="#section-boilerplate.3-1.4.2.2.1" class="pilcrow">¶</a></p>
+</li>
+ <li class="toc ulEmpty" id="section-boilerplate.3-1.4.2.3">
+ <p id="section-boilerplate.3-1.4.2.3.1"><a href="#section-4.3"
class="xref">4.3</a>. <a href="#name-block-data-encryption-and-d"
class="xref">Block data encryption and decryption</a><a
href="#section-boilerplate.3-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
@@ -1108,7 +1121,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<p id="section-boilerplate.3-1.10.1"><a href="#section-10"
class="xref">10</a>. <a href="#name-normative-references"
class="xref">Normative References</a><a href="#section-boilerplate.3-1.10.1"
class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.11">
- <p id="section-boilerplate.3-1.11.1"><a href="#section-appendix.a"
class="xref"></a> <a href="#name-authors-address" class="xref">Author's
Address</a><a href="#section-boilerplate.3-1.11.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.11.1"><a href="#section-appendix.a"
class="xref"></a> <a href="#name-authors-addresses" class="xref">Authors'
Addresses</a><a href="#section-boilerplate.3-1.11.1" class="pilcrow">¶</a></p>
</li>
</ul>
</nav>
@@ -1120,11 +1133,11 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-1" class="section-number selfRef">1. </a><a
href="#name-introduction" class="section-name selfRef">Introduction</a>
</h2>
<p id="section-1-1">
- This document contains the GNU Name System (GNS) technical
specification
- for secure, censorship-resistant and decentralised name resolution.<a
href="#section-1-1" class="pilcrow">¶</a></p>
+ This document contains the GNU Name System (GNS) technical specification
+ for secure, censorship-resistant and decentralised name resolution.<a
href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
- This document defines the normative wire format of resource records,
resolution processes,
- cryptographic routines and security considerations for use by
implementors.<a href="#section-1-2" class="pilcrow">¶</a></p>
+ This document defines the normative wire format of resource records,
resolution processes,
+ cryptographic routines and security considerations for use by
implementors.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3"><a href="#section-1-3" class="pilcrow">¶</a></p>
</section>
</div>
@@ -1134,14 +1147,14 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-2" class="section-number selfRef">2. </a><a
href="#name-zones" class="section-name selfRef">Zones</a>
</h2>
<p id="section-2-1">
- A zone in GNS is defined by a public/private ECC key pair (x,x*P),
- where P is the generator of an elliptic curve, x is the private key and
- x*P the corresponding public key.
- The keys are constructed using the Curve25519 ECC scheme as defined in
- <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>.
- The public key "x*P" is used to uniquely identify and refer to the
zone.
- Records published in the zone are signed using a private key derived
- from the private key "x" as described in <a href="#publish"
class="xref">Section 4</a>.<a href="#section-2-1" class="pilcrow">¶</a></p>
+ A zone in GNS is defined by a public/private ECC key pair (x,x*P),
+ where P is the generator of an elliptic curve, x is the private key and
+ x*P the corresponding public key.
+ The keys are constructed using the Ed25519 ECC scheme as defined in
+ <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>.
+ The public key "x*P" is used to uniquely identify and refer to the zone.
+ Records published in the zone are signed using a private key derived
+ from the private key "x" as described in <a href="#publish"
class="xref">Section 4</a>.<a href="#section-2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="rrecords">
@@ -1150,25 +1163,25 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-3" class="section-number selfRef">3. </a><a
href="#name-resource-records" class="section-name selfRef">Resource records</a>
</h2>
<p id="section-3-1">
- A GNS resource record holds the data of a specific record in a zone.
- The resource record wire format is defined as follows:<a
href="#section-3-1" class="pilcrow">¶</a></p>
+ A GNS resource record holds the data of a specific record in a zone.
+ The resource record format is defined as follows:<a href="#section-3-1"
class="pilcrow">¶</a></p>
<div id="figure_gnsrecord">
<figure id="figure-1">
<div class="artwork art-text alignLeft" id="section-3-2.1">
<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+ 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>
</div>
@@ -1176,29 +1189,29 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<dl class="dlParallel" id="section-3-4">
<dt id="section-3-4.1">EXPIRATION</dt>
<dd id="section-3-4.2">
- Denotes the absolute expiration date of the record.
- In microseconds since midnight (0 hour), January 1, 1970 in network
- byte order.<a href="#section-3-4.2" class="pilcrow">¶</a>
+ Denotes the absolute expiration date of the record.
+ In microseconds since midnight (0 hour), January 1, 1970 in network
+ byte order.<a href="#section-3-4.2" class="pilcrow">¶</a>
</dd>
<dt id="section-3-4.3">DATA SIZE</dt>
<dd id="section-3-4.4">
- The resource record data length in bytes and network byte order.<a
href="#section-3-4.4" class="pilcrow">¶</a>
+ The size of the DATA field in bytes and in network byte order.<a
href="#section-3-4.4" class="pilcrow">¶</a>
</dd>
<dt id="section-3-4.5">TYPE</dt>
<dd id="section-3-4.6">
- The resource record type. This type can be one of the GNS resource
- records as defined in <a href="#gnsrecords" class="xref">Section
3.2</a> or a DNS record
- type as defined in <span>[<a href="#RFC1035"
class="xref">RFC1035</a>]</span> or any of the
- complementary standardized DNS resource record types.<a
href="#section-3-4.6" class="pilcrow">¶</a>
+ The resource record type. This type can be one of the GNS resource
+ records as defined in <a href="#gnsrecords" class="xref">Section 3.2</a>
or a DNS record
+ type as defined in <span>[<a href="#RFC1035"
class="xref">RFC1035</a>]</span> or any of the
+ complementary standardized DNS resource record types.<a
href="#section-3-4.6" class="pilcrow">¶</a>
</dd>
<dt id="section-3-4.7">FLAGS</dt>
<dd id="section-3-4.8">
- Resource record flags. Flags are defined in <a href="#flags"
class="xref">Section 3.1</a>.<a href="#section-3-4.8" class="pilcrow">¶</a>
+ Resource record flags. Flags are defined in <a href="#flags"
class="xref">Section 3.1</a>.<a href="#section-3-4.8" class="pilcrow">¶</a>
</dd>
<dt id="section-3-4.9">DATA</dt>
<dd id="section-3-4.10">
- The resource record data payload. The contents are defined by the
- respective type of the resource record.<a href="#section-3-4.10"
class="pilcrow">¶</a>
+ The resource record data payload. The contents are defined by the
+ respective type of the resource record.<a href="#section-3-4.10"
class="pilcrow">¶</a>
</dd>
</dl>
<div id="flags">
@@ -1207,40 +1220,40 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a
href="#name-flags" class="section-name selfRef">Flags</a>
</h3>
<p id="section-3.1-1">
- Flags indicate metadata surrounding the resource record. A flag
- value of 0 indicates that all flags are unset. The following
- illustrates the flag distribution in the 32-bit flag value of a
- resource record:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
+ Flags indicate metadata surrounding the resource record. A flag
+ value of 0 indicates that all flags are unset. The following
+ illustrates the flag distribution in the 32-bit flag value of a
+ resource record:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<div id="figure_flag">
<figure id="figure-2">
<div class="artwork art-text alignLeft" id="section-3.1-2.1">
<pre>
- ... 5 4 3 2 1 0
- ------+--------+--------+--------+--------+--------+
- / ... | SHADOW | EXPREL | / | PRIVATE| / |
- ------+--------+--------+--------+--------+--------+
- </pre>
+ ... 5 4 3 2 1 0
+ ------+--------+--------+--------+--------+--------+
+ / ... | SHADOW | EXPREL | / | PRIVATE| / |
+ ------+--------+--------+--------+--------+--------+
+ </pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure
2</a></figcaption></figure>
</div>
<p id="section-3.1-3">
- where:<a href="#section-3.1-3" class="pilcrow">¶</a></p>
+ where:<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3.1-4">
<dt id="section-3.1-4.1">SHADOW</dt>
<dd id="section-3.1-4.2">
- If this flag is set, this record should not be used unless all
(other)
- records with an absolute expiration time have expired.<a
href="#section-3.1-4.2" class="pilcrow">¶</a>
+ If this flag is set, this record should not be used unless all (other)
+ records with an absolute expiration time have expired.<a
href="#section-3.1-4.2" class="pilcrow">¶</a>
</dd>
<dt id="section-3.1-4.3">EXPREL</dt>
<dd id="section-3.1-4.4">
- The expiration time value of the record is a relative time and not
- an absolute time. This flag can be ignored by a resolver.<a
href="#section-3.1-4.4" class="pilcrow">¶</a>
+ The expiration time value of the record is a relative time and not
+ an absolute time. This flag can be ignored by a resolver.<a
href="#section-3.1-4.4" class="pilcrow">¶</a>
</dd>
<dt id="section-3.1-4.5">PRIVATE</dt>
<dd id="section-3.1-4.6">
- This is a private record of this peer and it should thus not be
- handed out to other peers. This flag should never be encountered by
- a resolver.<a href="#section-3.1-4.6" class="pilcrow">¶</a>
+ This is a private record of this peer and it should thus not be
+ handed out to other peers. This flag should never be encountered by
+ a resolver.<a href="#section-3.1-4.6" class="pilcrow">¶</a>
</dd>
</dl>
</section>
@@ -1255,14 +1268,14 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<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 |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ </pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure
3</a></figcaption></figure>
</div>
@@ -1276,247 +1289,268 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<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 and published
- together in a single block in the DHT.
- A resource records block is published under a key which is derived from
- the respective label of the contained records.
- Given a label, the DHT key "q" is derived as follows:<a
href="#section-4-1" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-4-2">
+ GNS resource records are published in a distributed hash table (DHT).
+ Resource records are grouped by their respective labels and published
+ together in a single block in the DHT.
+ A resource records block is published under a key which is derived from
+ the zone key and the respective label of the contained records.
+ Given a label, the DHT key "q" is derived as follows:<a
href="#section-4-1" class="pilcrow">¶</a></p>
+<div id="blinding">
+<section id="section-4.1">
+ <h3 id="name-key-derivations">
+<a href="#section-4.1" class="section-number selfRef">4.1. </a><a
href="#name-key-derivations" class="section-name selfRef">Key derivations</a>
+ </h3>
+<div class="artwork art-text alignLeft" id="section-4.1-1">
<pre>
- PRK_h := HKDF-Extract ("key-derivation", x*P)
- h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
- d := h*x mod p
- q := SHA512 (d*P)
- </pre><a href="#section-4-2" class="pilcrow">¶</a>
+ PRK_h := HKDF-Extract ("key-derivation", x*P)
+ h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
+ d := h*x mod p
+ q := SHA512 (d*P)
+ </pre><a href="#section-4.1-1" class="pilcrow">¶</a>
</div>
-<p id="section-4-3">
- We use a hash-based key derivation function (HKDF) as defined in
- <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>. We use
HMAC-SHA512 for the extraction
- phase and HMAC-SHA256 for the expansion phase.<a href="#section-4-3"
class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-4-4">
- <dt id="section-4-4.1">h</dt>
- <dd id="section-4-4.2">
- is key material retrieved using an HKDF using the string
- "key-derivation" as salt and the public key "x*P" as initial keying
- material. The label and string "gns" are concatenated and used in the
- HKDF expansion phase.<a href="#section-4-4.2" class="pilcrow">¶</a>
+<p id="section-4.1-2">
+ We use a hash-based key derivation function (HKDF) as defined in
+ <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>. We use
HMAC-SHA512 for the extraction
+ phase and HMAC-SHA256 for the expansion phase.<a href="#section-4.1-2"
class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-4.1-3">
+ <dt id="section-4.1-3.1">h</dt>
+ <dd id="section-4.1-3.2">
+ is key material retrieved using an HKDF using the string
+ "key-derivation" as salt and the public zone key "x*P" as initial keying
+ material. The label and string "gns" are concatenated and used in the
+ HKDF expansion phase.<a href="#section-4.1-3.2" class="pilcrow">¶</a>
</dd>
- <dt id="section-4-4.3">d</dt>
- <dd id="section-4-4.4">
- is a private key derived from the zone key "x" using the keying
- material "h" (512 bit) and "p" is a prime as defined in
- <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>.<a
href="#section-4-4.4" class="pilcrow">¶</a>
+ <dt id="section-4.1-3.3">x</dt>
+ <dd id="section-4.1-3.4">
+ is the private zone key as defined in <span>[<a href="#RFC8032"
class="xref">RFC8032</a>]</span>.<a href="#section-4.1-3.4"
class="pilcrow">¶</a>
</dd>
- <dt id="section-4-4.5">q</dt>
- <dd id="section-4-4.6">
- Is the DHT key under which the resource records block is published.
- It is the SHA512 hash over the public key "d*P" corresponding to the
- derived private key "d".<a href="#section-4-4.6"
class="pilcrow">¶</a>
+ <dt id="section-4.1-3.5">P</dt>
+ <dd id="section-4.1-3.6">
+ is the base point of the curve Ed25519 as defined in
+ <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>.<a
href="#section-4.1-3.6" class="pilcrow">¶</a>
</dd>
- </dl>
+ <dt id="section-4.1-3.7">label</dt>
+ <dd id="section-4.1-3.8">
+ under wich the resource records are published.<a href="#section-4.1-3.8"
class="pilcrow">¶</a>
+</dd>
+ <dt id="section-4.1-3.9">d</dt>
+ <dd id="section-4.1-3.10">
+ is a private key derived from the zone key "x" using the keying
+ material "h" (512 bit) and "p" is the group order as defined in
+ <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>.<a
href="#section-4.1-3.10" class="pilcrow">¶</a>
+</dd>
+ <dt id="section-4.1-3.11">q</dt>
+ <dd id="section-4.1-3.12">
+ Is the DHT key under which the resource records block is published.
+ It is the SHA512 hash over the public key "d*P" corresponding to the
+ derived private key "d".<a href="#section-4.1-3.12" class="pilcrow">¶</a>
+</dd>
+ </dl>
+</section>
+</div>
<div id="wire">
-<section id="section-4.1">
+<section id="section-4.2">
<h3 id="name-resource-records-block">
-<a href="#section-4.1" class="section-number selfRef">4.1. </a><a
href="#name-resource-records-block" class="section-name selfRef">Resource
records block</a>
+<a href="#section-4.2" class="section-number selfRef">4.2. </a><a
href="#name-resource-records-block" class="section-name selfRef">Resource
records block</a>
</h3>
-<p id="section-4.1-1">
- GNS records are grouped by their labels are published as a single
- block in the DHT.
- The contained resource records are encrypted using a symmetric
- encryption scheme.
- A GNS resource records block has the following format:<a
href="#section-4.1-1" class="pilcrow">¶</a></p>
+<p id="section-4.2-1">
+ 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 resource records block has the following format:<a
href="#section-4.2-1" class="pilcrow">¶</a></p>
<div id="figure_record_block">
<figure id="figure-4">
- <div class="artwork art-text alignLeft" id="section-4.1-2.1">
+ <div class="artwork art-text alignLeft" id="section-4.2-2.1">
<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIGNATURE |
- | |
- | |
- | |
- | |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | BDATA SIZE | PURPOSE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | BDATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | SIGNATURE |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | BDATA SIZE | PURPOSE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | BDATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ </pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure
4</a></figcaption></figure>
</div>
-<p id="section-4.1-3">where:<a href="#section-4.1-3" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-4.1-4">
- <dt id="section-4.1-4.1">SIGNATURE</dt>
- <dd id="section-4.1-4.2">
- A 512-bit ECDSA signature. This field contains a 512-bit ECDSA
- signature over the data following the PUBLIC KEY field.
- The signature is create using the derived private key "d".<a
href="#section-4.1-4.2" class="pilcrow">¶</a>
+<p id="section-4.2-3">where:<a href="#section-4.2-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-4.2-4">
+ <dt id="section-4.2-4.1">SIGNATURE</dt>
+ <dd id="section-4.2-4.2">
+ A 512-bit ECDSA deterministic signature compliant with
+ <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span>. The
signature is computed over the data
+ following the PUBLIC KEY field.
+ The signature is created using the derived private key "d" (see
+ <a href="#publish" class="xref">Section 4</a>).<a
href="#section-4.2-4.2" class="pilcrow">¶</a>
</dd>
- <dt id="section-4.1-4.3">PUBLIC KEY</dt>
- <dd id="section-4.1-4.4">
- The 256-bit ECC public key "d*P" to be used to verify SIGNATURE.<a
href="#section-4.1-4.4" class="pilcrow">¶</a>
+ <dt id="section-4.2-4.3">PUBLIC KEY</dt>
+ <dd id="section-4.2-4.4">
+ The 256-bit ECC public key "d*P" to be used to verify SIGNATURE.<a
href="#section-4.2-4.4" class="pilcrow">¶</a>
</dd>
- <dt id="section-4.1-4.5">BDATA SIZE</dt>
- <dd id="section-4.1-4.6">
- A 32-bit value containing the length of the following data
(PURPOSE,
- EXPIRATION, BDATA) in network byte order.<a
href="#section-4.1-4.6" class="pilcrow">¶</a>
+ <dt id="section-4.2-4.5">BDATA SIZE</dt>
+ <dd id="section-4.2-4.6">
+ A 32-bit value containing the length of the following data (PURPOSE,
+ EXPIRATION, BDATA) in network byte order.<a href="#section-4.2-4.6"
class="pilcrow">¶</a>
</dd>
- <dt id="section-4.1-4.7">PURPOSE</dt>
- <dd id="section-4.1-4.8">
- A 32-bit signature purpose flag. This field MUST be 15 (in network
- byte order).<a href="#section-4.1-4.8" class="pilcrow">¶</a>
+ <dt id="section-4.2-4.7">PURPOSE</dt>
+ <dd id="section-4.2-4.8">
+ A 32-bit signature purpose flag. This field MUST be 15 (in network
+ byte order).<a href="#section-4.2-4.8" class="pilcrow">¶</a>
</dd>
- <dt id="section-4.1-4.9">EXPIRATION</dt>
- <dd id="section-4.1-4.10">
- The resource records block expiration time. This is the expiration
- time of the resource record contained within this block with the
- smallest expiration time.
- This is a 64-bit absolute date in microseconds since midnight
- (0 hour), January 1, 1970 in network byte order.<a
href="#section-4.1-4.10" class="pilcrow">¶</a>
+ <dt id="section-4.2-4.9">EXPIRATION</dt>
+ <dd id="section-4.2-4.10">
+ The resource records block expiration time. This is the expiration
+ time of the resource record contained within this block with the
+ smallest expiration time.
+ This is a 64-bit absolute date in microseconds since midnight
+ (0 hour), January 1, 1970 in network byte order.<a
href="#section-4.2-4.10" class="pilcrow">¶</a>
</dd>
- <dt id="section-4.1-4.11">BDATA</dt>
- <dd id="section-4.1-4.12">
- The encrypted resource records with a total size of "BDATA
SIZE".<a href="#section-4.1-4.12" class="pilcrow">¶</a>
+ <dt id="section-4.2-4.11">BDATA</dt>
+ <dd id="section-4.2-4.12">
+ The encrypted resource records with a total size of "BDATA SIZE".<a
href="#section-4.2-4.12" class="pilcrow">¶</a>
</dd>
</dl>
</section>
</div>
-<section id="section-4.2">
- <h3 id="name-block-data-encryption">
-<a href="#section-4.2" class="section-number selfRef">4.2. </a><a
href="#name-block-data-encryption" class="section-name selfRef">Block data
encryption</a>
+<section id="section-4.3">
+ <h3 id="name-block-data-encryption-and-d">
+<a href="#section-4.3" class="section-number selfRef">4.3. </a><a
href="#name-block-data-encryption-and-d" class="section-name selfRef">Block
data encryption and decryption</a>
</h3>
-<p id="section-4.2-1">
- Given a GNS record block a symmetric encryption scheme is used to
- en-/decrypt "BDATA". The keys are derived from the record label
- and a public key "d*P", where "d" is an ECDSA private key and "P"
- is the EC generator. "d" is derived from the private key "x" of a GNS
- zone.
- Both label and public key and "x*P" are implicity known by a GNS
- resolver while "d*P" is provided within the resource records block.
- The keying material "K" and initialization vector "IV"
- are derived as follows:<a href="#section-4.2-1"
class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-4.2-2">
+<p id="section-4.3-1">
+ A symmetric encryption scheme is used to en-/decrypt the "BDATA" field
+ in a GNS record block. The keys are derived from the record label
+ and the public key "d*P". The secret scalar "d" is derived from "h"
+ and private key "x" of a GNS zone.
+ Both label and public key and "x*P" are implicity known by a GNS
+ resolver while "d*P" is provided within the resource records block.
+ The validity of "d" can be checked by computing "h" from "x*P" and
+ label and verifying that "d*P = h*x*P". This step is mandatory to
+ prevent spoofed records to be verified and decrypted correctly.
+ The keying material "K" and initialization vector "IV" for the
+ symmetric encryption/decryption are derived as follows:<a
href="#section-4.3-1" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-4.3-2">
<pre>
- PRK_h := HKDF-Extract ("key-derivation", x*P)
- h := HKDF-Expand (PRK_h, l | "gns", 512 / 8)
- d := h*x mod p
- PRK_kiv := HKDF-Extract (d*P, l)
- K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
- IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
- </pre><a href="#section-4.2-2" class="pilcrow">¶</a>
+ PRK_kiv := HKDF-Extract (d*P, label)
+ K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
+ IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
+ </pre><a href="#section-4.3-2" class="pilcrow">¶</a>
</div>
-<p id="section-4.2-3">
- We use a hash-based key derivation function (HKDF) as defined in
- <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>. We use
HMAC-SHA512 for the extraction
- phase and HMAC-SHA256 for the expansion phase.
- The output keying material is 64 octets (512 bit) for the symmetric
- keys and 32 octets (256 bit) for the initialization vector.
- We divide the resulting keying material "K" into a 256-bit AES key
- "Kaes" and a 256-bit TWOFISH key "Ktwo":<a href="#section-4.2-3"
class="pilcrow">¶</a></p>
+<p id="section-4.3-3">
+ We use a hash-based key derivation function (HKDF) as defined in
+ <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>. We use
HMAC-SHA512 for the extraction
+ phase and HMAC-SHA256 for the expansion phase.
+ The output keying material is 64 octets (512 bit) for the symmetric
+ keys and 32 octets (256 bit) for the initialization vector.
+ We divide the resulting keying material "K" into a 256-bit AES key
+ "Kaes" and a 256-bit TWOFISH key "Ktwo":<a href="#section-4.3-3"
class="pilcrow">¶</a></p>
<div id="figure_hkdf_keys">
<figure id="figure-5">
- <div class="artwork art-text alignLeft" id="section-4.2-4.1">
+ <div class="artwork art-text alignLeft" id="section-4.3-4.1">
<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES KEY (Kaes) |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH KEY (Ktwo) |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES KEY (Kaes) |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH KEY (Ktwo) |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ </pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure
5</a></figcaption></figure>
</div>
-<p id="section-4.2-5">
- Similarly, we divide "IV" into a 128-bit initialization vector IVaes
- and a 128-bit initialization vector IVtwo:<a href="#section-4.2-5"
class="pilcrow">¶</a></p>
+<p id="section-4.3-5">
+ Similarly, we divide "IV" into a 128-bit initialization vector IVaes
+ and a 128-bit initialization vector IVtwo:<a href="#section-4.3-5"
class="pilcrow">¶</a></p>
<div id="figure_hkdf_ivs">
<figure id="figure-6">
- <div class="artwork art-text alignLeft" id="section-4.2-6.1">
+ <div class="artwork art-text alignLeft" id="section-4.3-6.1">
<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES IV (IVaes) |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH IV (IVtwo) |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES IV (IVaes) |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH IV (IVtwo) |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ </pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure
6</a></figcaption></figure>
</div>
-<p id="section-4.2-7">
- The symmetric keys and IVs are used for a AES+TWOFISH combined
- cipher. Both ciphers are used in Cipher FeedBack (CFB) mode.<a
href="#section-4.2-7" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-4.2-8">
+<p id="section-4.3-7">
+ The symmetric keys and IVs are used for a AES+TWOFISH combined
+ cipher. Both ciphers are used in Cipher FeedBack (CFB) mode.<a
href="#section-4.3-7" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-4.3-8">
<pre>
- RDATA := AES(Kaes, IVaes, TWOFISH(Ktwo, IVtwo, BDATA))
- BDATA := TWOFISH(Ktwo, IVtwo, AES(Kaes, IVaes, RDATA))
- </pre><a href="#section-4.2-8" class="pilcrow">¶</a>
+ RDATA := AES(Kaes, IVaes, TWOFISH(Ktwo, IVtwo, BDATA))
+ BDATA := TWOFISH(Ktwo, IVtwo, AES(Kaes, IVaes, RDATA))
+ </pre><a href="#section-4.3-8" class="pilcrow">¶</a>
</div>
-<p id="section-4.2-9">
- The decrypted RDATA has the following format:<a
href="#section-4.2-9" class="pilcrow">¶</a></p>
+<p id="section-4.3-9">
+ The decrypted RDATA has the following format:<a href="#section-4.3-9"
class="pilcrow">¶</a></p>
<div id="figure_rdata">
<figure id="figure-7">
- <div class="artwork art-text alignLeft" id="section-4.2-10.1">
+ <div class="artwork art-text alignLeft" id="section-4.3-10.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 /
- +-----+-----+-----+-----+ /
- / /
- / /
- / /
- </pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | RR COUNT | EXPIRA- /
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ / -TION | DATA SIZE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TYPE | FLAGS |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA SIZE | TYPE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | FLAGS | DATA /
+ +-----+-----+-----+-----+ /
+ / /
+ / /
+ / /
+ </pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure
7</a></figcaption></figure>
</div>
-<p id="section-4.2-11">where:<a href="#section-4.2-11"
class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-4.2-12">
- <dt id="section-4.2-12.1">RR COUNT</dt>
- <dd id="section-4.2-12.2">
- A 32-bit value containing the number of resource records which are
- following.<a href="#section-4.2-12.2" class="pilcrow">¶</a>
+<p id="section-4.3-11">where:<a href="#section-4.3-11"
class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-4.3-12">
+ <dt id="section-4.3-12.1">RR COUNT</dt>
+ <dd id="section-4.3-12.2">
+ A 32-bit value containing the number of resource records which are
+ following in network byte order.<a href="#section-4.3-12.2"
class="pilcrow">¶</a>
</dd>
</dl>
-<p id="section-4.2-13">
- is followed by a set of resource records with the respective wire
- formats defined in <a href="#rrecords" class="xref">Section 3</a>.<a
href="#section-4.2-13" class="pilcrow">¶</a></p>
+<p id="section-4.3-13">
+ is followed by a set of resource records with the respective
+ formats defined in <a href="#rrecords" class="xref">Section 3</a>.<a
href="#section-4.3-13" class="pilcrow">¶</a></p>
</section>
</section>
</div>
@@ -1526,7 +1560,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-5" class="section-number selfRef">5. </a><a
href="#name-internationalization-and-ch" class="section-name
selfRef">Internationalization and Character Encoding</a>
</h2>
<p id="section-5-1">
- TODO<a href="#section-5-1" class="pilcrow">¶</a></p>
+ TODO<a href="#section-5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="security">
@@ -1535,7 +1569,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-6" class="section-number selfRef">6. </a><a
href="#name-security-considerations" class="section-name selfRef">Security
Considerations</a>
</h2>
<p id="section-6-1">
- TODO<a href="#section-6-1" class="pilcrow">¶</a></p>
+ TODO<a href="#section-6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="resolution">
@@ -1544,7 +1578,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-7" class="section-number selfRef">7. </a><a
href="#name-record-resolution" class="section-name selfRef">Record
Resolution</a>
</h2>
<p id="section-7-1">
- TODO<a href="#section-7-1" class="pilcrow">¶</a></p>
+ TODO<a href="#section-7-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="revocation">
@@ -1553,7 +1587,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-8" class="section-number selfRef">8. </a><a
href="#name-namespace-revocation" class="section-name selfRef">Namespace
Revocation</a>
</h2>
<p id="section-8-1">
- TODO<a href="#section-8-1" class="pilcrow">¶</a></p>
+ TODO<a href="#section-8-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana">
@@ -1562,7 +1596,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-9" class="section-number selfRef">9. </a><a
href="#name-iana-considerations" class="section-name selfRef">IANA
Considerations</a>
</h2>
<p id="section-9-1">
- This will be fun<a href="#section-9-1" class="pilcrow">¶</a></p>
+ This will be fun<a href="#section-9-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-10">
@@ -1576,17 +1610,22 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<dt id="RFC5869">[RFC5869]</dt>
<dd>
<span class="refAuthor">Krawczyk, H.</span><span class="refAuthor"> and P.
Eronen</span>, <span class="refTitle">"
- HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
+ HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
"</span>, <span class="seriesInfo">RFC 5869</span>, <span
class="seriesInfo">DOI 10.17487/RFC5869</span>, <time datetime="2010-05">May
2010</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc5869";>https://www.rfc-editor.org/info/rfc5869</a>></span>.
</dd>
-<dt id="RFC7748">[RFC7748]</dt>
+<dt id="RFC6979">[RFC6979]</dt>
+ <dd>
+<span class="refAuthor">Pornin, T.</span>, <span class="refTitle">"
+ Deterministic Usage of the Digital Signature Algorithm (DSA) and
Elliptic Curve Digital Signature Algorithm (ECDSA)
+ "</span>, <span class="seriesInfo">RFC 6979</span>, <span
class="seriesInfo">DOI 10.17487/RFC6979</span>, <time datetime="2013-08">August
2013</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc6979";>https://www.rfc-editor.org/info/rfc6979</a>></span>.
</dd>
+<dt id="RFC8032">[RFC8032]</dt>
<dd>
-<span class="refAuthor">Langley, A.</span><span class="refAuthor">, Hamburg,
M.</span><span class="refAuthor">, and S. Turner</span>, <span
class="refTitle">"Elliptic Curves for Security"</span>, <span
class="seriesInfo">RFC 7748</span>, <span class="seriesInfo">DOI
10.17487/RFC7748</span>, <time datetime="2016-01">January 2016</time>,
<span><<a
href="https://www.rfc-editor.org/info/rfc7748";>https://www.rfc-editor.org/info/rfc7748</a>></span>.
</dd>
+<span class="refAuthor">Josefsson, S.</span><span class="refAuthor"> and I.
Liusvaara</span>, <span class="refTitle">"Edwards-Curve Digital Signature
Algorithm (EdDSA)"</span>, <span class="seriesInfo">RFC 8032</span>, <span
class="seriesInfo">DOI 10.17487/RFC8032</span>, <time
datetime="2017-01">January 2017</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc8032";>https://www.rfc-editor.org/info/rfc8032</a>></span>.
</dd>
</dl>
</section>
<div id="authors-addresses">
<section id="section-appendix.a">
- <h2 id="name-authors-address">
-<a href="#name-authors-address" class="section-name selfRef">Author's
Address</a>
+ <h2 id="name-authors-addresses">
+<a href="#name-authors-addresses" class="section-name selfRef">Authors'
Addresses</a>
</h2>
<address class="vcard">
<div dir="auto" class="left"><span class="fn nameRole">Martin
Schanzenbach</span></div>
@@ -1601,6 +1640,32 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="mailto:address@hidden"; class="email">address@hidden</a>
</div>
</address>
+<address class="vcard">
+ <div dir="auto" class="left"><span class="fn nameRole">Christian
Grothoff</span></div>
+<div dir="auto" class="left"><span class="org">GNUnet e.V.</span></div>
+<div dir="auto" class="left"><span class="street-address">Boltzmannstrasse
3</span></div>
+<div dir="auto" class="left">
+<span class="postal-code">85748</span> <span class="locality">Garching</span>
+</div>
+<div dir="auto" class="left"><span class="country-name">Germany</span></div>
+<div class="email">
+<span>Email:</span>
+<a href="mailto:address@hidden"; class="email">address@hidden</a>
+</div>
+</address>
+<address class="vcard">
+ <div dir="auto" class="left"><span class="fn nameRole">Bernd
Fix</span></div>
+<div dir="auto" class="left"><span class="org">GNUnet e.V.</span></div>
+<div dir="auto" class="left"><span class="street-address">Boltzmannstrasse
3</span></div>
+<div dir="auto" class="left">
+<span class="postal-code">85748</span> <span class="locality">Garching</span>
+</div>
+<div dir="auto" class="left"><span class="country-name">Germany</span></div>
+<div class="email">
+<span>Email:</span>
+<a href="mailto:address@hidden"; class="email">address@hidden</a>
+</div>
+</address>
</section>
</div>
<script>var toc = document.getElementById("toc");
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index 525fb95..0bf8079 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -2,10 +2,11 @@
-Independent Stream M.S. Schanzenbach
-Internet-Draft GNUnet e.V.
-Intended status: Informational 23 July 2019
-Expires: 24 January 2020
+Independent Stream M. Schanzenbach
+Internet-Draft C. Grothhoff
+Intended status: Informational B. Fix
+Expires: 24 January 2020 GNUnet e.V.
+ 23 July 2019
The GNU Name System Specification
@@ -52,8 +53,7 @@ Copyright Notice
-
-Schanzenbach Expires 24 January 2020 [Page 1]
+Schanzenbach, et al. Expires 24 January 2020 [Page 1]
Internet-Draft The GNU Name System July 2019
@@ -66,15 +66,16 @@ Table of Contents
3.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. GNS resource record types . . . . . . . . . . . . . . . . 4
4. Publishing records . . . . . . . . . . . . . . . . . . . . . 4
- 4.1. Resource records block . . . . . . . . . . . . . . . . . 5
- 4.2. Block data encryption . . . . . . . . . . . . . . . . . . 6
+ 4.1. Key derivations . . . . . . . . . . . . . . . . . . . . . 4
+ 4.2. Resource records block . . . . . . . . . . . . . . . . . 5
+ 4.3. Block data encryption and decryption . . . . . . . . . . 6
5. Internationalization and Character Encoding . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 8
8. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Normative References . . . . . . . . . . . . . . . . . . . . 9
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
@@ -92,16 +93,15 @@ Table of Contents
A zone in GNS is defined by a public/private ECC key pair (x,x*P),
where P is the generator of an elliptic curve, x is the private key
and x*P the corresponding public key. The keys are constructed using
- the Curve25519 ECC scheme as defined in [RFC7748]. The public key
- "x*P" is used to uniquely identify and refer to the zone. Records
+ the Ed25519 ECC scheme as defined in [RFC8032]. The public key "x*P"
+ is used to uniquely identify and refer to the zone. Records
published in the zone are signed using a private key derived from the
private key "x" as described in Section 4.
3. Resource records
A GNS resource record holds the data of a specific record in a zone.
- The resource record wire format is defined as follows:
-
+ The resource record format is defined as follows:
@@ -109,23 +109,23 @@ Table of Contents
-Schanzenbach Expires 24 January 2020 [Page 2]
+Schanzenbach, et al. Expires 24 January 2020 [Page 2]
Internet-Draft The GNU Name System July 2019
- 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 /
+ +-----+-----+-----+-----+ /
+ / /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 1
@@ -135,7 +135,7 @@ Internet-Draft The GNU Name System
July 2019
microseconds since midnight (0 hour), January 1, 1970 in network
byte order.
- DATA SIZE The resource record data length in bytes and network byte
+ DATA SIZE The size of the DATA field in bytes and in network byte
order.
TYPE The resource record type. This type can be one of the GNS
@@ -155,17 +155,17 @@ Internet-Draft The GNU Name System
July 2019
illustrates the flag distribution in the 32-bit flag value of a
resource record:
- ... 5 4 3 2 1 0
- ------+--------+--------+--------+--------+--------+
- / ... | SHADOW | EXPREL | / | PRIVATE| / |
- ------+--------+--------+--------+--------+--------+
+ ... 5 4 3 2 1 0
+ ------+--------+--------+--------+--------+--------+
+ / ... | SHADOW | EXPREL | / | PRIVATE| / |
+ ------+--------+--------+--------+--------+--------+
Figure 2
-Schanzenbach Expires 24 January 2020 [Page 3]
+Schanzenbach, et al. Expires 24 January 2020 [Page 3]
Internet-Draft The GNU Name System July 2019
@@ -186,13 +186,13 @@ Internet-Draft The GNU Name System
July 2019
The 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
@@ -201,86 +201,95 @@ Internet-Draft The GNU Name System
July 2019
GNS resource records are published in a distributed hash table (DHT).
Resource records are grouped by their respective labels and published
together in a single block in the DHT. A resource records block is
- published under a key which is derived from the respective label of
- the contained records. Given a label, the DHT key "q" is derived as
- follows:
+ published under a key which is derived from the zone key and the
+ respective label of the contained records. Given a label, the DHT
+ key "q" is derived as follows:
+
+4.1. Key derivations
- PRK_h := HKDF-Extract ("key-derivation", x*P)
- h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
- d := h*x mod p
- q := SHA512 (d*P)
+ PRK_h := HKDF-Extract ("key-derivation", x*P)
+ h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
+ d := h*x mod p
+ q := SHA512 (d*P)
We use a hash-based key derivation function (HKDF) as defined in
[RFC5869]. We use HMAC-SHA512 for the extraction phase and HMAC-
SHA256 for the expansion phase.
h is key material retrieved using an HKDF using the string "key-
- derivation" as salt and the public key "x*P" as initial keying
- material. The label and string "gns" are concatenated and used in
- the HKDF expansion phase.
+ derivation" as salt and the public zone key "x*P" as initial
-Schanzenbach Expires 24 January 2020 [Page 4]
+Schanzenbach, et al. Expires 24 January 2020 [Page 4]
Internet-Draft The GNU Name System July 2019
+ keying material. The label and string "gns" are concatenated and
+ used in the HKDF expansion phase.
+
+ x is the private zone key as defined in [RFC8032].
+
+ P is the base point of the curve Ed25519 as defined in [RFC8032].
+
+ label under wich the resource records are published.
+
d is a private key derived from the zone key "x" using the keying
- material "h" (512 bit) and "p" is a prime as defined in [RFC7748].
+ material "h" (512 bit) and "p" is the group order as defined in
+ [RFC8032].
q Is the DHT key under which the resource records block is
published. It is the SHA512 hash over the public key "d*P"
corresponding to the derived private key "d".
-4.1. Resource records block
+4.2. Resource records block
- GNS records are grouped by their labels are published as a single
+ 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 resource records block has the
following format:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIGNATURE |
- | |
- | |
- | |
- | |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | BDATA SIZE | PURPOSE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | BDATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | SIGNATURE |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | BDATA SIZE | PURPOSE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | BDATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 5]
+
+Internet-Draft The GNU Name System July 2019
+
Figure 4
where:
- SIGNATURE A 512-bit ECDSA signature. This field contains a 512-bit
- ECDSA signature over the data following the PUBLIC KEY field. The
- signature is create using the derived private key "d".
-
-
-
-
-
-Schanzenbach Expires 24 January 2020 [Page 5]
-
-Internet-Draft The GNU Name System July 2019
-
+ SIGNATURE A 512-bit ECDSA deterministic signature compliant with
+ [RFC6979]. The signature is computed over the data following the
+ PUBLIC KEY field. The signature is created using the derived
+ private key "d" (see Section 4).
PUBLIC KEY The 256-bit ECC public key "d*P" to be used to verify
SIGNATURE.
@@ -300,78 +309,73 @@ Internet-Draft The GNU Name System
July 2019
BDATA The encrypted resource records with a total size of "BDATA
SIZE".
-4.2. Block data encryption
+4.3. Block data encryption and decryption
- Given a GNS record block a symmetric encryption scheme is used to
- en-/decrypt "BDATA". The keys are derived from the record label and
- a public key "d*P", where "d" is an ECDSA private key and "P" is the
- EC generator. "d" is derived from the private key "x" of a GNS zone.
- Both label and public key and "x*P" are implicity known by a GNS
- resolver while "d*P" is provided within the resource records block.
- The keying material "K" and initialization vector "IV" are derived as
- follows:
+ A symmetric encryption scheme is used to en-/decrypt the "BDATA"
+ field in a GNS record block. The keys are derived from the record
+ label and the public key "d*P". The secret scalar "d" is derived
+ from "h" and private key "x" of a GNS zone. Both label and public
+ key and "x*P" are implicity known by a GNS resolver while "d*P" is
+ provided within the resource records block. The validity of "d" can
+ be checked by computing "h" from "x*P" and label and verifying that
+ "d*P = h*x*P". This step is mandatory to prevent spoofed records to
+ be verified and decrypted correctly. The keying material "K" and
+ initialization vector "IV" for the symmetric encryption/decryption
+ are derived as follows:
- PRK_h := HKDF-Extract ("key-derivation", x*P)
- h := HKDF-Expand (PRK_h, l | "gns", 512 / 8)
- d := h*x mod p
- PRK_kiv := HKDF-Extract (d*P, l)
- K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
- IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
+ PRK_kiv := HKDF-Extract (d*P, label)
+ K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
+ IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
We use a hash-based key derivation function (HKDF) as defined in
[RFC5869]. We use HMAC-SHA512 for the extraction phase and HMAC-
SHA256 for the expansion phase. The output keying material is 64
- octets (512 bit) for the symmetric keys and 32 octets (256 bit) for
- the initialization vector. We divide the resulting keying material
- "K" into a 256-bit AES key "Kaes" and a 256-bit TWOFISH key "Ktwo":
-
-
-
-
-
-
-Schanzenbach Expires 24 January 2020 [Page 6]
+Schanzenbach, et al. Expires 24 January 2020 [Page 6]
Internet-Draft The GNU Name System July 2019
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES KEY (Kaes) |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH KEY (Ktwo) |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ octets (512 bit) for the symmetric keys and 32 octets (256 bit) for
+ the initialization vector. We divide the resulting keying material
+ "K" into a 256-bit AES key "Kaes" and a 256-bit TWOFISH key "Ktwo":
+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES KEY (Kaes) |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH KEY (Ktwo) |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 5
Similarly, we divide "IV" into a 128-bit initialization vector IVaes
and a 128-bit initialization vector IVtwo:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES IV (IVaes) |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH IV (IVtwo) |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES IV (IVaes) |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH IV (IVtwo) |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 6
The symmetric keys and IVs are used for a AES+TWOFISH combined
cipher. Both ciphers are used in Cipher FeedBack (CFB) mode.
- RDATA := AES(Kaes, IVaes, TWOFISH(Ktwo, IVtwo, BDATA))
- BDATA := TWOFISH(Ktwo, IVtwo, AES(Kaes, IVaes, RDATA))
+ RDATA := AES(Kaes, IVaes, TWOFISH(Ktwo, IVtwo, BDATA))
+ BDATA := TWOFISH(Ktwo, IVtwo, AES(Kaes, IVaes, RDATA))
The decrypted RDATA has the following format:
@@ -385,46 +389,42 @@ Internet-Draft The GNU Name System
July 2019
-
-
-
-
-Schanzenbach Expires 24 January 2020 [Page 7]
+Schanzenbach, et al. Expires 24 January 2020 [Page 7]
Internet-Draft The GNU Name System July 2019
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | RR COUNT | EXPIRA- /
- +-----+-----+-----+-----+-----+-----+-----+-----+
- / -TION | DATA SIZE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TYPE | FLAGS |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / /
- / /
- / /
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | RR COUNT | EXPIRA- /
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ / -TION | DATA SIZE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TYPE | FLAGS |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA SIZE | TYPE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | FLAGS | DATA /
+ +-----+-----+-----+-----+ /
+ / /
+ / /
+ / /
Figure 7
where:
RR COUNT A 32-bit value containing the number of resource records
- which are following.
+ which are following in network byte order.
- is followed by a set of resource records with the respective wire
- formats defined in Section 3.
+ is followed by a set of resource records with the respective formats
+ defined in Section 3.
5. Internationalization and Character Encoding
@@ -445,7 +445,7 @@ Internet-Draft The GNU Name System
July 2019
-Schanzenbach Expires 24 January 2020 [Page 8]
+Schanzenbach, et al. Expires 24 January 2020 [Page 8]
Internet-Draft The GNU Name System July 2019
@@ -465,11 +465,17 @@ Internet-Draft The GNU Name System
July 2019
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
- [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
- for Security", RFC 7748, DOI 10.17487/RFC7748, January
- 2016, <https://www.rfc-editor.org/info/rfc7748>.
+ [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
+ Algorithm (DSA) and Elliptic Curve Digital Signature
+ Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
+ 2013, <https://www.rfc-editor.org/info/rfc6979>.
-Author's Address
+ [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
+ Signature Algorithm (EdDSA)", RFC 8032,
+ DOI 10.17487/RFC8032, January 2017,
+ <https://www.rfc-editor.org/info/rfc8032>.
+
+Authors' Addresses
Martin Schanzenbach
GNUnet e.V.
@@ -480,6 +486,56 @@ Author's Address
Email: address@hidden
+ Christian Grothoff
+ GNUnet e.V.
+ Boltzmannstrasse 3
+ 85748 Garching
+ Germany
+
+ Email: address@hidden
+
+
+ Bernd Fix
+ GNUnet e.V.
+ Boltzmannstrasse 3
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 9]
+
+Internet-Draft The GNU Name System July 2019
+
+
+ 85748 Garching
+ Germany
+
+ Email: address@hidden
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -501,4 +557,4 @@ Author's Address
-Schanzenbach Expires 24 January 2020 [Page 9]
+Schanzenbach, et al. Expires 24 January 2020 [Page 10]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 514d257..8e78652 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -11,511 +11,568 @@
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"; category="info"
docName="draft-schanzen-gns-00" ipr="trust200902" obsoletes="" updates=""
submissionType="IETF" xml:lang="en" version="3">
- <!-- xml2rfc v2v3 conversion 2.26.0 -->
- <front>
- <title abbrev="The GNU Name System">
- The GNU Name System Specification
- </title>
- <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-00"/>
- <author fullname="Martin Schanzenbach" initials="M.S."
surname="Schanzenbach">
- <organization>GNUnet e.V.</organization>
- <address>
- <postal>
- <street>Boltzmannstrasse 3</street>
- <city>Garching</city>
- <code>85748</code>
- <country>DE</country>
- </postal>
- <email>address@hidden</email>
- </address>
- </author>
- <date day="23" month="July" year="2019"/>
- <!-- Meta-data Declarations -->
- <area>General</area>
- <workgroup>Independent Stream</workgroup>
- <keyword>name systems</keyword>
- <abstract>
- <t>This document contains the GNU Name System (GNS) technical
specification.</t>
- </abstract>
- </front>
- <middle>
- <section anchor="introduction" numbered="true" toc="default">
- <name>Introduction</name>
- <t>
- This document contains the GNU Name System (GNS) technical
specification
- for secure, censorship-resistant and decentralised name resolution.
- </t>
- <t>
- This document defines the normative wire format of resource records,
resolution processes,
- cryptographic routines and security considerations for use by
implementors.
- </t>
- <t>
+ <!-- xml2rfc v2v3 conversion 2.26.0 -->
+ <front>
+ <title abbrev="The GNU Name System">
+ The GNU Name System Specification
+ </title>
+ <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-00"/>
+ <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach">
+ <organization>GNUnet e.V.</organization>
+ <address>
+ <postal>
+ <street>Boltzmannstrasse 3</street>
+ <city>Garching</city>
+ <code>85748</code>
+ <country>DE</country>
+ </postal>
+ <email>address@hidden</email>
+ </address>
+ </author>
+ <author fullname="Christian Grothoff" initials="C." surname="Grothhoff">
+ <organization>GNUnet e.V.</organization>
+ <address>
+ <postal>
+ <street>Boltzmannstrasse 3</street>
+ <city>Garching</city>
+ <code>85748</code>
+ <country>DE</country>
+ </postal>
+ <email>address@hidden</email>
+ </address>
+ </author>
+ <author fullname="Bernd Fix" initials="B." surname="Fix">
+ <organization>GNUnet e.V.</organization>
+ <address>
+ <postal>
+ <street>Boltzmannstrasse 3</street>
+ <city>Garching</city>
+ <code>85748</code>
+ <country>DE</country>
+ </postal>
+ <email>address@hidden</email>
+ </address>
+ </author>
- </t>
- </section>
- <section anchor="zones" numbered="true" toc="default">
- <name>Zones</name>
- <t>
- A zone in GNS is defined by a public/private ECC key pair (x,x*P),
- where P is the generator of an elliptic curve, x is the private key and
- x*P the corresponding public key.
- The keys are constructed using the Curve25519 ECC scheme as defined in
- <xref target="RFC7748" />.
- The public key "x*P" is used to uniquely identify and refer to the
zone.
- Records published in the zone are signed using a private key derived
- from the private key "x" as described in <xref target="publish" />.
- </t>
- </section>
- <section anchor="rrecords" numbered="true" toc="default">
- <name>Resource records</name>
- <t>
- A GNS resource record holds the data of a specific record in a zone.
- The resource record wire format is defined as follows:
- </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 /
- +-----+-----+-----+-----+ /
- / /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
- <t>where:</t>
- <dl>
- <dt>EXPIRATION</dt>
- <dd>
- Denotes the absolute expiration date of the record.
- In microseconds since midnight (0 hour), January 1, 1970 in network
- byte order.
- </dd>
- <dt>DATA SIZE</dt>
- <dd>
- The resource record data length in bytes and network byte order.
- </dd>
- <dt>TYPE</dt>
- <dd>
- The resource record type. This type can be one of the GNS resource
- records as defined in <xref target="gnsrecords" /> or a DNS record
- type as defined in <xref target="RFC1035" /> or any of the
- complementary standardized DNS resource record types.
- </dd>
- <dt>FLAGS</dt>
- <dd>
- Resource record flags. Flags are defined in <xref target="flags" />.
- </dd>
- <dt>DATA</dt>
- <dd>
- The resource record data payload. The contents are defined by the
- respective type of the resource record.
- </dd>
- </dl>
- <section anchor="flags" numbered="true" toc="default">
- <name>Flags</name>
- <t>
- Flags indicate metadata surrounding the resource record. A flag
- value of 0 indicates that all flags are unset. The following
- illustrates the flag distribution in the 32-bit flag value of a
- resource record:</t>
- <figure anchor="figure_flag">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- ... 5 4 3 2 1 0
- ------+--------+--------+--------+--------+--------+
- / ... | SHADOW | EXPREL | / | PRIVATE| / |
- ------+--------+--------+--------+--------+--------+
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
- <t>
- where:
- </t>
- <dl>
- <dt>SHADOW</dt>
- <dd>
- If this flag is set, this record should not be used unless all
(other)
- records with an absolute expiration time have expired.
- </dd>
- <dt>EXPREL</dt>
- <dd>
- The expiration time value of the record is a relative time and not
- an absolute time. This flag can be ignored by a resolver.
- </dd>
- <dt>PRIVATE</dt>
- <dd>
- This is a private record of this peer and it should thus not be
- handed out to other peers. This flag should never be encountered by
- a resolver.
- </dd>
- </dl>
- </section>
- <section anchor="gnsrecords" numbered="true" toc="default">
- <name>GNS resource record types</name>
+ <date day="23" month="July" year="2019"/>
+ <!-- Meta-data Declarations -->
+ <area>General</area>
+ <workgroup>Independent Stream</workgroup>
+ <keyword>name systems</keyword>
+ <abstract>
+ <t>This document contains the GNU Name System (GNS) technical
specification.</t>
+ </abstract>
+ </front>
+ <middle>
+ <section anchor="introduction" numbered="true" toc="default">
+ <name>Introduction</name>
+ <t>
+ This document contains the GNU Name System (GNS) technical specification
+ for secure, censorship-resistant and decentralised name resolution.
+ </t>
+ <t>
+ This document defines the normative wire format of resource records,
resolution processes,
+ cryptographic routines and security considerations for use by implementors.
+ </t>
+ <t>
- <t>The 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 |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
- </section>
- </section>
+ </t>
+ </section>
+ <section anchor="zones" numbered="true" toc="default">
+ <name>Zones</name>
+ <t>
+ A zone in GNS is defined by a public/private ECC key pair (x,x*P),
+ where P is the generator of an elliptic curve, x is the private key and
+ x*P the corresponding public key.
+ The keys are constructed using the Ed25519 ECC scheme as defined in
+ <xref target="RFC8032" />.
+ The public key "x*P" is used to uniquely identify and refer to the zone.
+ Records published in the zone are signed using a private key derived
+ from the private key "x" as described in <xref target="publish" />.
+ </t>
+ </section>
+ <section anchor="rrecords" numbered="true" toc="default">
+ <name>Resource records</name>
+ <t>
+ A GNS resource record holds the data of a specific record in a zone.
+ The resource record format is defined as follows:
+ </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 /
+ +-----+-----+-----+-----+ /
+ / /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ <t>where:</t>
+ <dl>
+ <dt>EXPIRATION</dt>
+ <dd>
+ Denotes the absolute expiration date of the record.
+ In microseconds since midnight (0 hour), January 1, 1970 in network
+ byte order.
+ </dd>
+ <dt>DATA SIZE</dt>
+ <dd>
+ The size of the DATA field in bytes and in network byte order.
+ </dd>
+ <dt>TYPE</dt>
+ <dd>
+ The resource record type. This type can be one of the GNS resource
+ records as defined in <xref target="gnsrecords" /> or a DNS record
+ type as defined in <xref target="RFC1035" /> or any of the
+ complementary standardized DNS resource record types.
+ </dd>
+ <dt>FLAGS</dt>
+ <dd>
+ Resource record flags. Flags are defined in <xref target="flags" />.
+ </dd>
+ <dt>DATA</dt>
+ <dd>
+ The resource record data payload. The contents are defined by the
+ respective type of the resource record.
+ </dd>
+ </dl>
+ <section anchor="flags" numbered="true" toc="default">
+ <name>Flags</name>
+ <t>
+ Flags indicate metadata surrounding the resource record. A flag
+ value of 0 indicates that all flags are unset. The following
+ illustrates the flag distribution in the 32-bit flag value of a
+ resource record:</t>
+ <figure anchor="figure_flag">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ ... 5 4 3 2 1 0
+ ------+--------+--------+--------+--------+--------+
+ / ... | SHADOW | EXPREL | / | PRIVATE| / |
+ ------+--------+--------+--------+--------+--------+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ <t>
+ where:
+ </t>
+ <dl>
+ <dt>SHADOW</dt>
+ <dd>
+ If this flag is set, this record should not be used unless all (other)
+ records with an absolute expiration time have expired.
+ </dd>
+ <dt>EXPREL</dt>
+ <dd>
+ The expiration time value of the record is a relative time and not
+ an absolute time. This flag can be ignored by a resolver.
+ </dd>
+ <dt>PRIVATE</dt>
+ <dd>
+ This is a private record of this peer and it should thus not be
+ handed out to other peers. This flag should never be encountered by
+ a resolver.
+ </dd>
+ </dl>
+ </section>
+ <section anchor="gnsrecords" numbered="true" toc="default">
+ <name>GNS resource record types</name>
- <section anchor="publish" numbered="true" toc="default">
- <name>Publishing records</name>
- <t>
- GNS resource records are published in a distributed hash table (DHT).
- Resource records are grouped by their respective labels and published
- together in a single block in the DHT.
- A resource records block is published under a key which is derived from
- the respective label of the contained records.
- 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", x*P)
- h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
- d := h*x mod p
- q := SHA512 (d*P)
- ]]></artwork>
- <t>
- We use a hash-based key derivation function (HKDF) as defined in
- <xref target="RFC5869" />. We use HMAC-SHA512 for the extraction
- phase and HMAC-SHA256 for the expansion phase.
- </t>
- <dl>
- <dt>h</dt>
- <dd>
- is key material retrieved using an HKDF using the string
- "key-derivation" as salt and the public key "x*P" as initial keying
- material. The label and string "gns" are concatenated and used in the
- HKDF expansion phase.
- </dd>
- <dt>d</dt>
- <dd>
- is a private key derived from the zone key "x" using the keying
- material "h" (512 bit) and "p" is a prime as defined in
- <xref target="RFC7748" />.
- </dd>
- <dt>q</dt>
- <dd>
- Is the DHT key under which the resource records block is published.
- It is the SHA512 hash over the public key "d*P" corresponding to the
- derived private key "d".
- </dd>
- </dl>
- <section anchor="wire" numbered="true" toc="default">
- <name>Resource records block</name>
- <t>
- GNS records are grouped by their labels are published as a single
- block in the DHT.
- The contained resource records are encrypted using a symmetric
- encryption scheme.
- A GNS resource records block has the following format:
- </t>
- <figure anchor="figure_record_block">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIGNATURE |
- | |
- | |
- | |
- | |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | BDATA SIZE | PURPOSE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | BDATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- ]]></artwork>
- </figure>
- <t>where:</t>
- <dl>
- <dt>SIGNATURE</dt>
- <dd>
- A 512-bit ECDSA signature. This field contains a 512-bit ECDSA
- signature over the data following the PUBLIC KEY field.
- The signature is create using the derived private key "d".
- </dd>
- <dt>PUBLIC KEY</dt>
- <dd>
- The 256-bit ECC public key "d*P" to be used to verify SIGNATURE.
- </dd>
- <dt>BDATA SIZE</dt>
- <dd>
- A 32-bit value containing the length of the following data
(PURPOSE,
- EXPIRATION, BDATA) in network byte order.
- </dd>
- <dt>PURPOSE</dt>
- <dd>
- A 32-bit signature purpose flag. This field MUST be 15 (in network
- byte order).
- </dd>
- <dt>EXPIRATION</dt>
- <dd>
- The resource records block expiration time. This is the expiration
- time of the resource record contained within this block with the
- smallest expiration time.
- This is a 64-bit absolute date in microseconds since midnight
- (0 hour), January 1, 1970 in network byte order.
- </dd>
- <dt>BDATA</dt>
- <dd>
- The encrypted resource records with a total size of "BDATA SIZE".
- </dd>
- </dl>
- </section>
- <section numbered="true" toc="default">
- <name>Block data encryption</name>
- <t>
- Given a GNS record block a symmetric encryption scheme is used to
- en-/decrypt "BDATA". The keys are derived from the record label
- and a public key "d*P", where "d" is an ECDSA private key and "P"
- is the EC generator. "d" is derived from the private key "x" of a GNS
- zone.
- Both label and public key and "x*P" are implicity known by a GNS
- resolver while "d*P" is provided within the resource records block.
- The keying material "K" and initialization vector "IV"
- are derived as follows:
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
- PRK_h := HKDF-Extract ("key-derivation", x*P)
- h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
- d := h*x mod p
- PRK_kiv := HKDF-Extract (d*P, label)
- K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
- IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
- ]]></artwork>
- <t>
- We use a hash-based key derivation function (HKDF) as defined in
- <xref target="RFC5869" />. We use HMAC-SHA512 for the extraction
- phase and HMAC-SHA256 for the expansion phase.
- The output keying material is 64 octets (512 bit) for the symmetric
- keys and 32 octets (256 bit) for the initialization vector.
- We divide the resulting keying material "K" into a 256-bit AES key
- "Kaes" and a 256-bit TWOFISH key "Ktwo":
- </t>
- <figure anchor="figure_hkdf_keys">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES KEY (Kaes) |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH KEY (Ktwo) |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
- <t>
- Similarly, we divide "IV" into a 128-bit initialization vector IVaes
- and a 128-bit initialization vector IVtwo:
- </t>
- <figure anchor="figure_hkdf_ivs">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES IV (IVaes) |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH IV (IVtwo) |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
+ <t>The 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 |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ </section>
+ </section>
- <t>
- The symmetric keys and IVs are used for a AES+TWOFISH combined
- cipher. Both ciphers are used in Cipher FeedBack (CFB) mode.
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
- RDATA := AES(Kaes, IVaes, TWOFISH(Ktwo, IVtwo, BDATA))
- BDATA := TWOFISH(Ktwo, IVtwo, AES(Kaes, IVaes, RDATA))
- ]]></artwork>
- <t>
- The decrypted RDATA has the following format:
- </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 /
- +-----+-----+-----+-----+ /
- / /
- / /
- / /
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
- <t>where:</t>
- <dl>
- <dt>RR COUNT</dt>
- <dd>
- A 32-bit value containing the number of resource records which are
- following.
- </dd>
- </dl>
- <t>
- is followed by a set of resource records with the respective wire
- formats defined in <xref target="rrecords" />.
- </t>
- </section>
- </section>
- <section anchor="encoding" numbered="true" toc="default">
- <name>Internationalization and Character Encoding</name>
- <t>
- TODO
- </t>
- </section>
- <section anchor="security" numbered="true" toc="default">
- <name>Security Considerations</name>
+ <section anchor="publish" numbered="true" toc="default">
+ <name>Publishing records</name>
+ <t>
+ GNS resource records are published in a distributed hash table (DHT).
+ Resource records are grouped by their respective labels and published
+ together in a single block in the DHT.
+ A resource records block is published under a key which is derived from
+ the zone key and the respective label of the contained records.
+ Given a label, the DHT key "q" is derived as follows:
+ </t>
+ <section anchor="blinding" numbered="true" toc="default">
+ <name>Key derivations</name>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ PRK_h := HKDF-Extract ("key-derivation", x*P)
+ h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
+ d := h*x mod p
+ q := SHA512 (d*P)
+ ]]></artwork>
+ <t>
+ We use a hash-based key derivation function (HKDF) as defined in
+ <xref target="RFC5869" />. We use HMAC-SHA512 for the extraction
+ phase and HMAC-SHA256 for the expansion phase.
+ </t>
+ <dl>
+ <dt>h</dt>
+ <dd>
+ is key material retrieved using an HKDF using the string
+ "key-derivation" as salt and the public zone key "x*P" as initial keying
+ material. The label and string "gns" are concatenated and used in the
+ HKDF expansion phase.
+ </dd>
+ <dt>x</dt>
+ <dd>
+ is the private zone key as defined in <xref target="RFC8032" />.
+ </dd>
+ <dt>P</dt>
+ <dd>
+ is the base point of the curve Ed25519 as defined in
+ <xref target="RFC8032" />.
+ </dd>
+ <dt>label</dt>
+ <dd>
+ under wich the resource records are published.
+ </dd>
+ <dt>d</dt>
+ <dd>
+ is a private key derived from the zone key "x" using the keying
+ material "h" (512 bit) and "p" is the group order as defined in
+ <xref target="RFC8032" />.
+ </dd>
+ <dt>q</dt>
+ <dd>
+ Is the DHT key under which the resource records block is published.
+ It is the SHA512 hash over the public key "d*P" corresponding to the
+ derived private key "d".
+ </dd>
+ </dl>
+ </section>
+ <section anchor="wire" numbered="true" toc="default">
+ <name>Resource records block</name>
+ <t>
+ 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 resource records block has the following format:
+ </t>
+ <figure anchor="figure_record_block">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | SIGNATURE |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | BDATA SIZE | PURPOSE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | BDATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ </figure>
+ <t>where:</t>
+ <dl>
+ <dt>SIGNATURE</dt>
+ <dd>
+ A 512-bit ECDSA deterministic signature compliant with
+ <xref target="RFC6979" />. The signature is computed over the data
+ following the PUBLIC KEY field.
+ The signature is created using the derived private key "d" (see
+ <xref target="publish" />).
+ </dd>
+ <dt>PUBLIC KEY</dt>
+ <dd>
+ The 256-bit ECC public key "d*P" to be used to verify SIGNATURE.
+ </dd>
+ <dt>BDATA SIZE</dt>
+ <dd>
+ A 32-bit value containing the length of the following data (PURPOSE,
+ EXPIRATION, BDATA) in network byte order.
+ </dd>
+ <dt>PURPOSE</dt>
+ <dd>
+ A 32-bit signature purpose flag. This field MUST be 15 (in network
+ byte order).
+ </dd>
+ <dt>EXPIRATION</dt>
+ <dd>
+ The resource records block expiration time. This is the expiration
+ time of the resource record contained within this block with the
+ smallest expiration time.
+ This is a 64-bit absolute date in microseconds since midnight
+ (0 hour), January 1, 1970 in network byte order.
+ </dd>
+ <dt>BDATA</dt>
+ <dd>
+ The encrypted resource records with a total size of "BDATA SIZE".
+ </dd>
+ </dl>
+ </section>
+ <section numbered="true" toc="default">
+ <name>Block data encryption and decryption</name>
+ <t>
+ A symmetric encryption scheme is used to en-/decrypt the "BDATA" field
+ in a GNS record block. The keys are derived from the record label
+ and the public key "d*P". The secret scalar "d" is derived from "h"
+ and private key "x" of a GNS zone.
+ Both label and public key and "x*P" are implicity known by a GNS
+ resolver while "d*P" is provided within the resource records block.
+ The validity of "d" can be checked by computing "h" from "x*P" and
+ label and verifying that "d*P = h*x*P". This step is mandatory to
+ prevent spoofed records to be verified and decrypted correctly.
+ The keying material "K" and initialization vector "IV" for the
+ symmetric encryption/decryption are derived as follows:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ PRK_kiv := HKDF-Extract (d*P, label)
+ K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
+ IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
+ ]]></artwork>
+ <t>
+ We use a hash-based key derivation function (HKDF) as defined in
+ <xref target="RFC5869" />. We use HMAC-SHA512 for the extraction
+ phase and HMAC-SHA256 for the expansion phase.
+ The output keying material is 64 octets (512 bit) for the symmetric
+ keys and 32 octets (256 bit) for the initialization vector.
+ We divide the resulting keying material "K" into a 256-bit AES key
+ "Kaes" and a 256-bit TWOFISH key "Ktwo":
+ </t>
+ <figure anchor="figure_hkdf_keys">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES KEY (Kaes) |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH KEY (Ktwo) |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ <t>
+ Similarly, we divide "IV" into a 128-bit initialization vector IVaes
+ and a 128-bit initialization vector IVtwo:
+ </t>
+ <figure anchor="figure_hkdf_ivs">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES IV (IVaes) |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH IV (IVtwo) |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+
+ <t>
+ The symmetric keys and IVs are used for a AES+TWOFISH combined
+ cipher. Both ciphers are used in Cipher FeedBack (CFB) mode.
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ RDATA := AES(Kaes, IVaes, TWOFISH(Ktwo, IVtwo, BDATA))
+ BDATA := TWOFISH(Ktwo, IVtwo, AES(Kaes, IVaes, RDATA))
+ ]]></artwork>
+ <t>
+ The decrypted RDATA has the following format:
+ </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 /
+ +-----+-----+-----+-----+ /
+ / /
+ / /
+ / /
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ <t>where:</t>
+ <dl>
+ <dt>RR COUNT</dt>
+ <dd>
+ A 32-bit value containing the number of resource records which are
+ following in network byte order.
+ </dd>
+ </dl>
+ <t>
+ is followed by a set of resource records with the respective
+ formats defined in <xref target="rrecords" />.
+ </t>
+ </section>
+ </section>
+ <section anchor="encoding" numbered="true" toc="default">
+ <name>Internationalization and Character Encoding</name>
+ <t>
+ TODO
+ </t>
+ </section>
+ <section anchor="security" numbered="true" toc="default">
+ <name>Security Considerations</name>
+ <t>
+ TODO
+ </t>
+ </section>
+ <section anchor="resolution" numbered="true" toc="default">
+ <name>Record Resolution</name>
+ <t>
+ TODO
+ </t>
+ </section>
+ <section anchor="revocation" numbered="true" toc="default">
+ <name>Namespace Revocation</name>
+ <t>
+ TODO
+ </t>
+ </section>
+ <section anchor="iana" numbered="true" toc="default">
+ <name>IANA Considerations</name>
+ <t>
+ This will be fun
+ </t>
+ </section>
+ <!-- iana -->
+ </middle>
+ <back>
+ <references>
+ <name>Normative References</name>
+ <reference anchor="RFC5869"
target="https://www.rfc-editor.org/info/rfc5869";>
+ <front>
+ <title>
+ HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
+ </title>
+ <author initials="H." surname="Krawczyk" fullname="H. Krawczyk">
+ <organization/>
+ </author>
+ <author initials="P." surname="Eronen" fullname="P. Eronen">
+ <organization/>
+ </author>
+ <date year="2010" month="May"/>
+ <abstract>
<t>
- TODO
+ This document specifies a simple Hashed Message Authentication Code
(HMAC)-based key derivation function (HKDF), which can be used as a building
block in various protocols and applications. The key derivation function (KDF)
is intended to support a wide range of applications and requirements, and is
conservative in its use of cryptographic hash functions. This document is not
an Internet Standards Track specification; it is published for informational
purposes.
</t>
- </section>
- <section anchor="resolution" numbered="true" toc="default">
- <name>Record Resolution</name>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="5869"/>
+ <seriesInfo name="DOI" value="10.17487/RFC5869"/>
+ </reference>
+ <reference anchor="RFC8032"
target="https://www.rfc-editor.org/info/rfc8032";>
+ <front>
+ <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
+ <author initials="S." surname="Josefsson" fullname="S. Josefsson">
+ <organization/>
+ </author>
+ <author initials="I." surname="Liusvaara" fullname="I. Liusvaara">
+ <organization/>
+ </author>
+ <date year="2017" month="January"/>
+ <abstract>
<t>
- TODO
+ This document describes elliptic curve signature scheme Edwards-curve
Digital Signature Algorithm (EdDSA). The algorithm is instantiated with
recommended parameters for the edwards25519 and edwards448 curves. An example
implementation and test vectors are provided.
</t>
- </section>
- <section anchor="revocation" numbered="true" toc="default">
- <name>Namespace Revocation</name>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="8032"/>
+ <seriesInfo name="DOI" value="10.17487/RFC8032"/>
+ </reference>
+ <reference anchor="RFC1035"
target="https://www.rfc-editor.org/info/rfc1035";>
+ <front>
+ <title>Domain names - implementation and specification</title>
+ <author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris">
+ <organization/>
+ </author>
+ <date year="1987" month="November"/>
+ <abstract>
<t>
- TODO
+ This RFC is the revised specification of the protocol and format used
in the implementation of the Domain Name System. It obsoletes RFC-883. This
memo documents the details of the domain name client - server communication.
</t>
- </section>
- <section anchor="iana" numbered="true" toc="default">
- <name>IANA Considerations</name>
+ </abstract>
+ </front>
+ <seriesInfo name="STD" value="13"/>
+ <seriesInfo name="RFC" value="1035"/>
+ <seriesInfo name="DOI" value="10.17487/RFC1035"/>
+ </reference>
+ <reference anchor="RFC6979"
target="https://www.rfc-editor.org/info/rfc6979";>
+ <front>
+ <title>
+ Deterministic Usage of the Digital Signature Algorithm (DSA) and
Elliptic Curve Digital Signature Algorithm (ECDSA)
+ </title>
+ <author initials="T." surname="Pornin" fullname="T. Pornin">
+ <organization/>
+ </author>
+ <date year="2013" month="August"/>
+ <abstract>
<t>
- This will be fun
+ This document defines a deterministic digital signature generation
procedure. Such signatures are compatible with standard Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital
signatures and can be processed with unmodified verifiers, which need not be
aware of the procedure described therein. Deterministic signatures retain the
cryptographic security features associated with digital signatures but can be
more easily implemented in vario [...]
</t>
- </section>
- <!-- iana -->
- </middle>
- <back>
- <references>
- <name>Normative References</name>
- <reference anchor="RFC5869"
target="https://www.rfc-editor.org/info/rfc5869";>
- <front>
- <title>
- HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
- </title>
- <author initials="H." surname="Krawczyk" fullname="H. Krawczyk">
- <organization/>
- </author>
- <author initials="P." surname="Eronen" fullname="P. Eronen">
- <organization/>
- </author>
- <date year="2010" month="May"/>
- <abstract>
- <t>
- This document specifies a simple Hashed Message Authentication
Code (HMAC)-based key derivation function (HKDF), which can be used as a
building block in various protocols and applications. The key derivation
function (KDF) is intended to support a wide range of applications and
requirements, and is conservative in its use of cryptographic hash functions.
This document is not an Internet Standards Track specification; it is published
for informational purposes.
- </t>
- </abstract>
- </front>
- <seriesInfo name="RFC" value="5869"/>
- <seriesInfo name="DOI" value="10.17487/RFC5869"/>
- </reference>
- <reference anchor="RFC7748"
target="https://www.rfc-editor.org/info/rfc7748";>
- <front>
- <title>Elliptic Curves for Security</title>
- <author initials="A." surname="Langley" fullname="A. Langley">
- <organization/>
- </author>
- <author initials="M." surname="Hamburg" fullname="M. Hamburg">
- <organization/>
- </author>
- <author initials="S." surname="Turner" fullname="S. Turner">
- <organization/>
- </author>
- <date year="2016" month="January"/>
- <abstract>
- <t>
- This memo specifies two elliptic curves over prime fields that
offer a high level of practical security in cryptographic applications,
including Transport Layer Security (TLS). These curves are intended to operate
at the ~128-bit and ~224-bit security level, respectively, and are generated
deterministically based on a list of required properties.
- </t>
- </abstract>
- </front>
- <seriesInfo name="RFC" value="7748"/>
- <seriesInfo name="DOI" value="10.17487/RFC7748"/>
- </reference>
- <reference anchor="RFC1035"
target="https://www.rfc-editor.org/info/rfc1035";>
- <front>
- <title>Domain names - implementation and specification</title>
- <author initials="P.V." surname="Mockapetris" fullname="P.V.
Mockapetris">
- <organization/>
- </author>
- <date year="1987" month="November"/>
- <abstract>
- <t>
- This RFC is the revised specification of the protocol and format
used in the implementation of the Domain Name System. It obsoletes RFC-883.
This memo documents the details of the domain name client - server
communication.
- </t>
- </abstract>
- </front>
- <seriesInfo name="STD" value="13"/>
- <seriesInfo name="RFC" value="1035"/>
- <seriesInfo name="DOI" value="10.17487/RFC1035"/>
- </reference>
- <!-- <reference anchor="ISO20022">
- <front>
- <title>ISO 20022 Financial Services - Universal financial industry
message scheme</title>
- <author>
- <organization>International Organization for
Standardization</organization>
- <address>
- <uri>http://www.iso.ch</uri>
- </address>
- </author>
- <date month="May" year="2013"/>
- </front>
- </reference>-->
- </references>
- <!-- Change Log
- v00 2017-07-23 MS Initial version
- -->
- </back>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="6979"/>
+ <seriesInfo name="DOI" value="10.17487/RFC6979"/>
+ </reference>
+ <!-- <reference anchor="ISO20022">
+ <front>
+ <title>ISO 20022 Financial Services - Universal financial industry
message scheme</title>
+ <author>
+ <organization>International Organization for
Standardization</organization>
+ <address>
+ <uri>http://www.iso.ch</uri>
+ </address>
+ </author>
+ <date month="May" year="2013"/>
+ </front>
+ </reference>-->
+ </references>
+ <!-- Change Log
+ v00 2017-07-23 MS Initial version
+ -->
+ </back>
</rfc>
--
To stop receiving notification emails like this one, please contact
address@hidden.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] [lsd0001] branch master updated: update crypto references; minor clarifications from bfix,
gnunet <=