commit 98ce51c39efce2bf98a87a2dfe4b7263a4187c6c
parent 1a254bc48bb4a72399dcaea2f19967d27c1b3fe9
Author: Schanzenbach, Martin <mschanzenbach@posteo.de>
Date: Sun, 19 Apr 2020 13:25:48 +0200
fix refs, security considerations, and revocation validation
Diffstat:
3 files changed, 390 insertions(+), 275 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
@@ -1224,12 +1224,22 @@ table {
</li>
<li class="toc ulEmpty" id="section-toc.1-1.7">
<p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>. <a href="#name-zone-revocation" class="xref">Zone Revocation</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
+<ul class="toc ulEmpty">
+<li class="toc ulEmpty" id="section-toc.1-1.7.2.1">
+ <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>. <a href="#name-verification" class="xref">Verification</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.8">
<p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>. <a href="#name-determining-the-root-zone-a" class="xref">Determining the Root Zone and Zone Governance</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9">
<p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
+<ul class="toc ulEmpty">
+<li class="toc ulEmpty" id="section-toc.1-1.9.2.1">
+ <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>. <a href="#name-revocations" class="xref">Revocations</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.10">
<p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
@@ -2388,19 +2398,23 @@ table {
The revocation message including the proof-of-work MAY be calculated
ahead of time to support timely revocation.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">
- For all occurences below, "scrypt" is the scrypt Password-based Key
- Derivation Function as defined in <span>[<a href="#RFC7914" class="xref">RFC7914</a>]</span> with the
- following parameters set:<a href="#section-7-3" class="pilcrow">¶</a></p>
+ For all occurences below, "Argon2d" is the Password-based Key
+ Derivation Function as defined in <span>[<a href="#Argon2" class="xref">Argon2</a>]</span> with the
+ following fixed parameters:<a href="#section-7-3" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-7-4">
<pre>
S := "gnunet-revocation-proof-of-work" /* Salt */
- N := 2
- r := 8 /* Block size */
- p := 2 /* Parallelization parameter */
+ t := 3 /* Iterations */
+ m := 1024 /* Memory size, 1 MiB */
+ T := 64 /* Tag (=output) length in bytes */
+ p := 1 /* Parallelization parameter */
+ v := 0x13 /* Version */
+ y := 0 /* Type (Argon2d) */
+ X, K is unused
</pre><a href="#section-7-4" class="pilcrow">¶</a>
</div>
<p id="section-7-5">
- The following the the basic data "REV" on which the proof-of work is
+ The following is the message string "P" on which the proof-of work is
calculated:<a href="#section-7-5" class="pilcrow">¶</a></p>
<div id="figure_revocation">
<figure id="figure-15">
@@ -2408,7 +2422,9 @@ table {
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
- | NONCE |
+ | POW |
+ +-----------------------------------------------+
+ | TIMESTAMP |
+-----------------------------------------------+
| PUBLIC KEY |
| |
@@ -2419,83 +2435,61 @@ table {
</div>
<figcaption><a href="#figure-15" class="selfRef">Figure 15</a></figcaption></figure>
</div>
-<p id="section-7-7">
- A single pass in the proof-of-work algorithm is defined as follows:<a href="#section-7-7" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal" id="section-7-8">
- <li id="section-7-8.1">Derive initial key material K from the REV data.<a href="#section-7-8.1" class="pilcrow">¶</a>
-</li>
-<li id="section-7-8.2">Derive IV material from the key material K.<a href="#section-7-8.2" class="pilcrow">¶</a>
-</li>
-<li id="section-7-8.3">Encrypt the REV data using K and IV.<a href="#section-7-8.3" class="pilcrow">¶</a>
-</li>
-<li id="section-7-8.4">Derive the proof of work from the encrypted REV and check against
- the proof condition.<a href="#section-7-8.4" class="pilcrow">¶</a>
-</li>
-</ol>
+<p id="section-7-7">where:<a href="#section-7-7" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-7-8">
+ <dt id="section-7-8.1">POW</dt>
+<dd id="section-7-8.2">
+ A 64-bit solution to the proof of work.<a href="#section-7-8.2" class="pilcrow">¶</a>
+</dd>
+<dt id="section-7-8.3">TIMESTAMP</dt>
+<dd id="section-7-8.4">
+ denotes the absolute 64-bit expiration date of the record.
+ In microseconds since midnight (0 hour), January 1, 1970 in network
+ byte order.<a href="#section-7-8.4" class="pilcrow">¶</a>
+</dd>
+<dt id="section-7-8.5">PUBLIC KEY</dt>
+<dd id="section-7-8.6">
+ A 512-bit ECDSA deterministic signature compliant with
+ <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span> over the public zone zk of the zone
+ which is revoked and corresponds to the key used in the proof-of-work.
+ The signature is created using the private zone key "d" (see
+ <a href="#zones" class="xref">Section 2</a>).<a href="#section-7-8.6" class="pilcrow">¶</a>
+</dd>
+</dl>
<p id="section-7-9">
- The first step in the PoW is a call to scrypt with the REV data as
- password parameter to derive the initial key material K:<a href="#section-7-9" class="pilcrow">¶</a></p>
-<figure id="figure-16">
- <div class="artwork art-text alignLeft" id="section-7-10.1">
-<pre>
- K := scrypt (P := REV, dkLen := 32)
- </pre>
-</div>
-<figcaption><a href="#figure-16" class="selfRef">Figure 16</a></figcaption></figure>
+ Traditionally, proof-of-work schemes require to find a "POW" such that
+ at least D leading zeroes are found in the hash result.
+ D is then referred to as the "difficulty" of the proof-of-work.
+ In order to reduce the variance in time it takes to calculate the
+ proof-of-work, we require that a number "Z" different PoWs must be
+ found that on average have "D" leading zeroes.<a href="#section-7-9" class="pilcrow">¶</a></p>
+<p id="section-7-10">
+ The resulting proofs may then published and disseminated. The concrete
+ dissemination and publication methods are out of scope of this
+ document. Given an average difficulty of "D", the proofs have an
+ expiration time of 365 days. With each additional bit difficulty, the
+ lifetime of the proof is prolonged for another 365 days.
+ Consequently, by calculating a more difficult PoW, the lifetime of the
+ proof can be increased on demand by the zone owner.<a href="#section-7-10" class="pilcrow">¶</a></p>
<p id="section-7-11">
- where dkLen denotes the intended output length in octets.
- The second step is to derive a 128 bit initialization vector using a
- Hash-based Key Derivation Function as defined in
- (<span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>).
- Specifically, HMAC-SHA512 is used for the
- extraction phase and HMAC-SHA256 for the expansion phase.<a href="#section-7-11" class="pilcrow">¶</a></p>
-<figure id="figure-17">
- <div class="artwork art-text alignLeft" id="section-7-12.1">
-<pre>
- PRK := HKDF-Extract ("gnunet-proof-of-work-iv", K)
- IV := HKDF-Expand (PRK,
- "gnunet-revocation-proof-of-work",
- 128 / 8);
-
- </pre>
-</div>
-<figcaption><a href="#figure-17" class="selfRef">Figure 17</a></figcaption></figure>
-<p id="section-7-13">
- We use the resulting keying material "K" as a 256-bit TWOFISH
- <span>[<a href="#TWOFISH" class="xref">TWOFISH</a>]</span> key and use IV as the corresponding
- initialization vector:<a href="#section-7-13" class="pilcrow">¶</a></p>
-<figure id="figure-18">
- <div class="artwork art-text alignLeft" id="section-7-14.1">
-<pre>
- EREV := TWOFISH(K, IV, REV)
- </pre>
-</div>
-<figcaption><a href="#figure-18" class="selfRef">Figure 18</a></figcaption></figure>
-<p id="section-7-15">
- The above EREV data object is again derived using the scrypt algorithm.
- The proof of work is complete, if the following inequality holds for a
- given NONCE:<a href="#section-7-15" class="pilcrow">¶</a></p>
-<figure id="figure-19">
- <div class="artwork art-text alignLeft" id="section-7-16.1">
-<pre>
- scrypt(P := EREV, dkLen := 64) < 2^(39)-1
-
- </pre>
-</div>
-<figcaption><a href="#figure-19" class="selfRef">Figure 19</a></figcaption></figure>
-<p id="section-7-17">
- where dkLen again denotes the intended output length in octets.
- The final revocation data object consists of a signature over the
- public of the zone which is revoked, the zone key itself and the just
- calculated proof-of-work.
- The resulting block is then published and disseminated. The concrete
- dissemination and publication methods are out of scope of this document.<a href="#section-7-17" class="pilcrow">¶</a></p>
+ Given that proof has been found, a revocation data object is defined
+ as follows:<a href="#section-7-11" class="pilcrow">¶</a></p>
<div id="figure_revocationdata">
-<figure id="figure-20">
- <div class="artwork art-text alignLeft" id="section-7-18.1">
+<figure id="figure-16">
+ <div class="artwork art-text alignLeft" id="section-7-12.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
+ | TIMESTAMP |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TTL |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | POW_0 |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | ... |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | POW_Z-1 |
+ +-----------------------------------------------+
| SIGNATURE |
| |
| |
@@ -2505,73 +2499,86 @@ table {
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
+ | SIZE (0x24) | PURPOSE (0x03) |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
| PUBLIC KEY |
| |
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- | NONCE |
- +-----------------------------------------------+
</pre>
</div>
-<figcaption><a href="#figure-20" class="selfRef">Figure 20</a></figcaption></figure>
+<figcaption><a href="#figure-16" class="selfRef">Figure 16</a></figcaption></figure>
</div>
-<p id="section-7-19">where:<a href="#section-7-19" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-7-20">
- <dt id="section-7-20.1">SIGNATURE</dt>
-<dd id="section-7-20.2">
+<p id="section-7-13">where:<a href="#section-7-13" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-7-14">
+ <dt id="section-7-14.1">TIMESTAMP</dt>
+<dd id="section-7-14.2">
+ denotes the absolute 64-bit expiration date of the revocation.
+ In microseconds since midnight (0 hour), January 1, 1970 in network
+ byte order.<a href="#section-7-14.2" class="pilcrow">¶</a>
+</dd>
+<dt id="section-7-14.3">TTL</dt>
+<dd id="section-7-14.4">
+ denotes the relative 64-bit time to live of of the record in
+ microseconds also in network byte order.<a href="#section-7-14.4" class="pilcrow">¶</a>
+</dd>
+<dt id="section-7-14.5">POW_i</dt>
+<dd id="section-7-14.6">
+ The POWs calculated as part of the proof-of-work. Each POW_i MUST
+ be unique in the set of POW values.<a href="#section-7-14.6" class="pilcrow">¶</a>
+</dd>
+<dt id="section-7-14.7">SIGNATURE</dt>
+<dd id="section-7-14.8">
A 512-bit ECDSA deterministic signature compliant with
<span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span> over the public zone zk of the zone
which is revoked and corresponds to the key used in the proof-of-work.
The signature is created using the private zone key "d" (see
- <a href="#zones" class="xref">Section 2</a>).<a href="#section-7-20.2" class="pilcrow">¶</a>
+ <a href="#zones" class="xref">Section 2</a>).<a href="#section-7-14.8" class="pilcrow">¶</a>
+</dd>
+<dt id="section-7-14.9">SIZE</dt>
+<dd id="section-7-14.10">
+ A 32-bit value containing the length of the signed data in bytes
+ (36 bytes) in network byte order.<a href="#section-7-14.10" class="pilcrow">¶</a>
+</dd>
+<dt id="section-7-14.11">PURPOSE</dt>
+<dd id="section-7-14.12">
+ A 32-bit signature purpose flag. This field MUST be 3 (in network
+ byte order).<a href="#section-7-14.12" class="pilcrow">¶</a>
</dd>
-<dt id="section-7-20.3">PUBLIC KEY</dt>
-<dd id="section-7-20.4">
+<dt id="section-7-14.13">PUBLIC KEY</dt>
+<dd id="section-7-14.14">
is the 256-bit public key "zk" of the zone which is being revoked and
the key to be used to verify SIGNATURE. The
wire format of this value is defined in <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>,
- Section 5.1.5.<a href="#section-7-20.4" class="pilcrow">¶</a>
-</dd>
-<dt id="section-7-20.5">NONCE</dt>
-<dd id="section-7-20.6">
- The nonce calculated as part of the proof-of-work.<a href="#section-7-20.6" class="pilcrow">¶</a>
+ Section 5.1.5.<a href="#section-7-14.14" class="pilcrow">¶</a>
</dd>
</dl>
-<p id="section-7-21">
- The signature over the public key covers a 32 bit pseuso header
- conceptually prefixed to the public key. The pseudo header includes
- the key length and signature purpose:<a href="#section-7-21" class="pilcrow">¶</a></p>
-<div id="figure_pkeywithpseudo">
-<figure id="figure-21">
- <div class="artwork art-text alignLeft" id="section-7-22.1">
-<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIZE (0x24) | PURPOSE (0x03) |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
-</div>
-<figcaption><a href="#figure-21" class="selfRef">Figure 21</a></figcaption></figure>
+<div id="revocation_verification">
+<section id="section-7.1">
+ <h3 id="name-verification">
+<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-verification" class="section-name selfRef">Verification</a>
+ </h3>
+<p id="section-7.1-1">
+ In order to verify a revocation the following steps must be taken,
+ in order:<a href="#section-7.1-1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="normal" id="section-7.1-2">
+ <li id="section-7.1-2.1">The current time MUST be between TIMESTAMP and
+ TIMESTAMP+TTL.<a href="#section-7.1-2.1" class="pilcrow">¶</a>
+</li>
+<li id="section-7.1-2.2">The signature MUST match the public key.<a href="#section-7.1-2.2" class="pilcrow">¶</a>
+</li>
+<li id="section-7.1-2.3">The set of POW values MUST NOT contain duplicates.<a href="#section-7.1-2.3" class="pilcrow">¶</a>
+</li>
+<li id="section-7.1-2.4">The average number of leading zeroes resulting from the provided
+ POW values D' MUST be greater than or equal to D.<a href="#section-7.1-2.4" class="pilcrow">¶</a>
+</li>
+<li id="section-7.1-2.5">The actual expiration time TIMESTAMP + (D'-D+1) * 365 days
+ is in the future.<a href="#section-7.1-2.5" class="pilcrow">¶</a>
+</li>
+</ol>
+</section>
</div>
-<p id="section-7-23">where:<a href="#section-7-23" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-7-24">
- <dt id="section-7-24.1">SIZE</dt>
-<dd id="section-7-24.2">
- A 32-bit value containing the length of the signed data in bytes
- (36 bytes) in network byte order.<a href="#section-7-24.2" class="pilcrow">¶</a>
-</dd>
-<dt id="section-7-24.3">PURPOSE</dt>
-<dd id="section-7-24.4">
- A 32-bit signature purpose flag. This field MUST be 3 (in network
- byte order).<a href="#section-7-24.4" class="pilcrow">¶</a>
-</dd>
-</dl>
</section>
</div>
<div id="governance">
@@ -2664,8 +2671,34 @@ table {
<h2 id="name-security-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
</h2>
-<p id="section-9-1">
- TODO<a href="#section-9-1" class="pilcrow">¶</a></p>
+<div id="security_rev">
+<section id="section-9.1">
+ <h3 id="name-revocations">
+<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-revocations" class="section-name selfRef">Revocations</a>
+ </h3>
+<p id="section-9.1-1">
+ Revocation payloads do NOT include a 'new' key for key replacement.
+ In inclusion of such a key would have two major disadvantages:<a href="#section-9.1-1" class="pilcrow">¶</a></p>
+<p id="section-9.1-2">
+ If revocation is used after a private key was compromised,
+ allowing key replacement would be dangerous, because if an
+ adversary took over the private key, the adversary could then
+ broadcast a revocation with a key replacement. For the replacement,
+ the compromised owner would have no chance to issue even a
+ revocation. Thus, allowing a revocation message to replace a private
+ key makes dealing with key compromise situations worse.<a href="#section-9.1-2" class="pilcrow">¶</a></p>
+<p id="section-9.1-3">
+ Sometimes, key revocations are used with the objective of changing
+ cryptosystems. Migration to another cryptosystem by replacing keys
+ via a revocation message would only be secure as long as both
+ cryptosystems are still secure against forgery. Such a planned,
+ non-emergency migration to another cryptosystem should be done by
+ running zones for both ciphersystems in parallel for a while. The
+ migration would conclude by revoking the legacy zone key only once
+ it is deemed no longer secure, and hopefully after most users have
+ migrated to the replacement.<a href="#section-9.1-3" class="pilcrow">¶</a></p>
+</section>
+</div>
</section>
</div>
<div id="iana">
@@ -2694,7 +2727,7 @@ The registry shall record for each entry:<a href="#section-10-1" class="pilcrow"
Served", as described in <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.
IANA is requested to populate this registry as follows:<a href="#section-10-3" class="pilcrow">¶</a></p>
<div id="figure_rrtypenums">
-<figure id="figure-22">
+<figure id="figure-17">
<div class="artwork art-text alignLeft" id="section-10-4.1">
<pre>
Number | Type | Contact | References
@@ -2708,7 +2741,7 @@ The registry shall record for each entry:<a href="#section-10-1" class="pilcrow"
FIXME We have a lot more?
</pre>
</div>
-<figcaption><a href="#figure-22" class="selfRef">Figure 22</a></figcaption></figure>
+<figcaption><a href="#figure-17" class="selfRef">Figure 17</a></figcaption></figure>
</div>
</section>
</div>
@@ -2870,9 +2903,9 @@ The registry shall record for each entry:<a href="#section-10-1" class="pilcrow"
<dt id="TWOFISH">[TWOFISH]</dt>
<dd>
<span class="refAuthor">Schneier, B.</span>, <span class="refTitle">"The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition"</span>, <time datetime="1999-03">March 1999</time>. </dd>
-<dt id="RFC7914">[RFC7914]</dt>
+<dt id="Argon2">[Argon2]</dt>
<dd>
-<span class="refAuthor">Percival, C.</span><span class="refAuthor"> and S. Josefsson</span>, <span class="refTitle">"The scrypt Password-Based Key Derivation Function"</span>, <span class="seriesInfo">RFC 7914</span>, <span class="seriesInfo">DOI 10.17487/RFC7914</span>, <time datetime="2016-08">August 2016</time>, <span><<a href="https://www.rfc-editor.org/info/rfc7914">https://www.rfc-editor.org/info/rfc7914</a>></span>. </dd>
+<span class="refAuthor">Biryukov, A.</span><span class="refAuthor">, Dinu, D.</span><span class="refAuthor">, Khovratovich, D.</span><span class="refAuthor">, and S. Josefsson</span>, <span class="refTitle">"The memory-hard Argon2 password hash and proof-of-work function"</span>, <time datetime="2020-03">March 2020</time>, <span><<a href="https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/">https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/</a>></span>. </dd>
</dl>
</section>
<div id="authors-addresses">
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
@@ -85,12 +85,14 @@ Table of Contents
6.2.5. VPN . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2.6. NICK . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 19
+ 7.1. Verification . . . . . . . . . . . . . . . . . . . . . . 23
8. Determining the Root Zone and Zone Governance . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
- 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
- 11. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 25
- 12. Normative References . . . . . . . . . . . . . . . . . . . . 27
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
+ 9.1. Revocations . . . . . . . . . . . . . . . . . . . . . . . 25
+ 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
+ 11. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 12. Normative References . . . . . . . . . . . . . . . . . . . . 28
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction
@@ -103,9 +105,7 @@ Table of Contents
threatening the global availability and integrity of information on
the Internet.
- DNS was not designed with security as a goal. This makes it very
- vulnerable, especially to attackers that have the technical
- capabilities of an entire nation state at their disposal. This
+
@@ -114,6 +114,9 @@ Schanzenbach, et al. Expires 13 May 2020 [Page 2]
Internet-Draft The GNU Name System November 2019
+ DNS was not designed with security as a goal. This makes it very
+ vulnerable, especially to attackers that have the technical
+ capabilities of an entire nation state at their disposal. This
specification describes a censorship-resistant, privacy-preserving
and decentralized name system: The GNU Name System (GNS). It is
designed to provide a secure alternative to DNS, especially when
@@ -160,9 +163,6 @@ Internet-Draft The GNU Name System November 2019
p is the prime of edwards25519 as defined in [RFC7748], i.e. 2^255
- 19.
- B is the group generator (X(P),Y(P)) of edwards25519 as defined in
- [RFC7748].
-
Schanzenbach, et al. Expires 13 May 2020 [Page 3]
@@ -170,6 +170,9 @@ Schanzenbach, et al. Expires 13 May 2020 [Page 3]
Internet-Draft The GNU Name System November 2019
+ B is the group generator (X(P),Y(P)) of edwards25519 as defined in
+ [RFC7748].
+
L is the prime-order subgroup of edwards25519 in [RFC7748].
zk is the ECDSA public key corresponding to d. It is defined in
@@ -215,9 +218,6 @@ Internet-Draft The GNU Name System November 2019
the GNS resource records as defined in Section 3 or a DNS record
type as defined in [RFC1035] or any of the complementary
standardized DNS resource record types. This value must be stored
- in network byte order. Note that values below 2^16 are reserved
- for allocation via IANA ([RFC6895]).
-
@@ -226,6 +226,9 @@ Schanzenbach, et al. Expires 13 May 2020 [Page 4]
Internet-Draft The GNU Name System November 2019
+ in network byte order. Note that values below 2^16 are reserved
+ for allocation via IANA ([RFC6895]).
+
FLAGS is a 32-bit resource record flags field (see below).
DATA the variable-length resource record data payload. The contents
@@ -274,9 +277,6 @@ Internet-Draft The GNU Name System November 2019
-
-
-
Schanzenbach, et al. Expires 13 May 2020 [Page 5]
Internet-Draft The GNU Name System November 2019
@@ -1073,21 +1073,27 @@ Internet-Draft The GNU Name System November 2019
work. The revocation message including the proof-of-work MAY be
calculated ahead of time to support timely revocation.
- For all occurences below, "scrypt" is the scrypt Password-based Key
- Derivation Function as defined in [RFC7914] with the following
- parameters set:
+ For all occurences below, "Argon2d" is the Password-based Key
+ Derivation Function as defined in [Argon2] with the following fixed
+ parameters:
S := "gnunet-revocation-proof-of-work" /* Salt */
- N := 2
- r := 8 /* Block size */
- p := 2 /* Parallelization parameter */
-
- The following the the basic data "REV" on which the proof-of work is
+ t := 3 /* Iterations */
+ m := 1024 /* Memory size, 1 MiB */
+ T := 64 /* Tag (=output) length in bytes */
+ p := 1 /* Parallelization parameter */
+ v := 0x13 /* Version */
+ y := 0 /* Type (Argon2d) */
+ X, K is unused
+
+ The following is the message string "P" on which the proof-of work is
calculated:
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
- | NONCE |
+ | POW |
+ +-----------------------------------------------+
+ | TIMESTAMP |
+-----------------------------------------------+
| PUBLIC KEY |
| |
@@ -1097,23 +1103,17 @@ Internet-Draft The GNU Name System November 2019
Figure 15
- A single pass in the proof-of-work algorithm is defined as follows:
-
- 1. Derive initial key material K from the REV data.
-
- 2. Derive IV material from the key material K.
-
- 3. Encrypt the REV data using K and IV.
+ where:
- 4. Derive the proof of work from the encrypted REV and check against
- the proof condition.
+ POW A 64-bit solution to the proof of work.
- The first step in the PoW is a call to scrypt with the REV data as
- password parameter to derive the initial key material K:
+ TIMESTAMP denotes the absolute 64-bit expiration date of the record.
+ In microseconds since midnight (0 hour), January 1, 1970 in
+ network byte order.
- K := scrypt (P := REV, dkLen := 32)
+ PUBLIC KEY A 512-bit ECDSA deterministic signature compliant with
+ [RFC6979] over the public zone zk of the zone which is revoked and
- Figure 16
@@ -1122,42 +1122,42 @@ Schanzenbach, et al. Expires 13 May 2020 [Page 20]
Internet-Draft The GNU Name System November 2019
- where dkLen denotes the intended output length in octets. The second
- step is to derive a 128 bit initialization vector using a Hash-based
- Key Derivation Function as defined in ([RFC5869]). Specifically,
- HMAC-SHA512 is used for the extraction phase and HMAC-SHA256 for the
- expansion phase.
+ corresponds to the key used in the proof-of-work. The signature
+ is created using the private zone key "d" (see Section 2).
+
+ Traditionally, proof-of-work schemes require to find a "POW" such
+ that at least D leading zeroes are found in the hash result. D is
+ then referred to as the "difficulty" of the proof-of-work. In order
+ to reduce the variance in time it takes to calculate the proof-of-
+ work, we require that a number "Z" different PoWs must be found that
+ on average have "D" leading zeroes.
+
+ The resulting proofs may then published and disseminated. The
+ concrete dissemination and publication methods are out of scope of
+ this document. Given an average difficulty of "D", the proofs have
+ an expiration time of 365 days. With each additional bit difficulty,
+ the lifetime of the proof is prolonged for another 365 days.
+ Consequently, by calculating a more difficult PoW, the lifetime of
+ the proof can be increased on demand by the zone owner.
+
+ Given that proof has been found, a revocation data object is defined
+ as follows:
+
+
+
+
+
- PRK := HKDF-Extract ("gnunet-proof-of-work-iv", K)
- IV := HKDF-Expand (PRK,
- "gnunet-revocation-proof-of-work",
- 128 / 8);
- Figure 17
- We use the resulting keying material "K" as a 256-bit TWOFISH
- [TWOFISH] key and use IV as the corresponding initialization vector:
- EREV := TWOFISH(K, IV, REV)
- Figure 18
- The above EREV data object is again derived using the scrypt
- algorithm. The proof of work is complete, if the following
- inequality holds for a given NONCE:
- scrypt(P := EREV, dkLen := 64) < 2^(39)-1
- Figure 19
- where dkLen again denotes the intended output length in octets. The
- final revocation data object consists of a signature over the public
- of the zone which is revoked, the zone key itself and the just
- calculated proof-of-work. The resulting block is then published and
- disseminated. The concrete dissemination and publication methods are
- out of scope of this document.
@@ -1180,6 +1180,16 @@ Internet-Draft The GNU Name System November 2019
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
+ | TIMESTAMP |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TTL |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | POW_0 |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | ... |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | POW_Z-1 |
+ +-----------------------------------------------+
| SIGNATURE |
| |
| |
@@ -1189,43 +1199,33 @@ Internet-Draft The GNU Name System November 2019
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
+ | SIZE (0x24) | PURPOSE (0x03) |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
| PUBLIC KEY |
| |
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- | NONCE |
- +-----------------------------------------------+
- Figure 20
+ Figure 16
where:
+ TIMESTAMP denotes the absolute 64-bit expiration date of the
+ revocation. In microseconds since midnight (0 hour), January 1,
+ 1970 in network byte order.
+
+ TTL denotes the relative 64-bit time to live of of the record in
+ microseconds also in network byte order.
+
+ POW_i The POWs calculated as part of the proof-of-work. Each POW_i
+ MUST be unique in the set of POW values.
+
SIGNATURE A 512-bit ECDSA deterministic signature compliant with
[RFC6979] over the public zone zk of the zone which is revoked and
corresponds to the key used in the proof-of-work. The signature
is created using the private zone key "d" (see Section 2).
- PUBLIC KEY is the 256-bit public key "zk" of the zone which is being
- revoked and the key to be used to verify SIGNATURE. The wire
- format of this value is defined in [RFC8032], Section 5.1.5.
-
- NONCE The nonce calculated as part of the proof-of-work.
-
- The signature over the public key covers a 32 bit pseuso header
- conceptually prefixed to the public key. The pseudo header includes
- the key length and signature purpose:
-
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIZE (0x24) | PURPOSE (0x03) |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
-
@@ -1234,16 +1234,33 @@ Schanzenbach, et al. Expires 13 May 2020 [Page 22]
Internet-Draft The GNU Name System November 2019
- Figure 21
-
- where:
-
SIZE A 32-bit value containing the length of the signed data in
bytes (36 bytes) in network byte order.
PURPOSE A 32-bit signature purpose flag. This field MUST be 3 (in
network byte order).
+ PUBLIC KEY is the 256-bit public key "zk" of the zone which is being
+ revoked and the key to be used to verify SIGNATURE. The wire
+ format of this value is defined in [RFC8032], Section 5.1.5.
+
+7.1. Verification
+
+ In order to verify a revocation the following steps must be taken, in
+ order:
+
+ 1. The current time MUST be between TIMESTAMP and TIMESTAMP+TTL.
+
+ 2. The signature MUST match the public key.
+
+ 3. The set of POW values MUST NOT contain duplicates.
+
+ 4. The average number of leading zeroes resulting from the provided
+ POW values D' MUST be greater than or equal to D.
+
+ 5. The actual expiration time TIMESTAMP + (D'-D+1) * 365 days is in
+ the future.
+
8. Determining the Root Zone and Zone Governance
The resolution of a GNS name must start in a given start zone
@@ -1265,6 +1282,14 @@ Internet-Draft The GNU Name System November 2019
In the following, we give examples how a local client resolver SHOULD
discover the start zone. The process given is not exhaustive and
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 23]
+
+Internet-Draft The GNU Name System November 2019
+
+
clients MAY suppliement it with other mechanisms or ignore it if the
particular application requires a different process.
@@ -1283,13 +1308,6 @@ Internet-Draft The GNU Name System November 2019
locally managed zone matches the suffix of the name to be resolved,
resolution SHOULD start from the respective local zone:
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 23]
-
-Internet-Draft The GNU Name System November 2019
-
-
Example name: www.example.gnu
Local zones:
fr = (d0,zk0)
@@ -1320,7 +1338,36 @@ Internet-Draft The GNU Name System November 2019
9. Security Considerations
- TODO
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 24]
+
+Internet-Draft The GNU Name System November 2019
+
+
+9.1. Revocations
+
+ Revocation payloads do NOT include a 'new' key for key replacement.
+ In inclusion of such a key would have two major disadvantages:
+
+ If revocation is used after a private key was compromised, allowing
+ key replacement would be dangerous, because if an adversary took over
+ the private key, the adversary could then broadcast a revocation with
+ a key replacement. For the replacement, the compromised owner would
+ have no chance to issue even a revocation. Thus, allowing a
+ revocation message to replace a private key makes dealing with key
+ compromise situations worse.
+
+ Sometimes, key revocations are used with the objective of changing
+ cryptosystems. Migration to another cryptosystem by replacing keys
+ via a revocation message would only be secure as long as both
+ cryptosystems are still secure against forgery. Such a planned, non-
+ emergency migration to another cryptosystem should be done by running
+ zones for both ciphersystems in parallel for a while. The migration
+ would conclude by revoking the legacy zone key only once it is deemed
+ no longer secure, and hopefully after most users have migrated to the
+ replacement.
10. IANA Considerations
@@ -1338,18 +1385,23 @@ Internet-Draft The GNU Name System November 2019
* References: Optionally, references describing the record type
(such as an RFC)
+ The registration policy for this sub-registry is "First Come First
+ Served", as described in [RFC8126]. IANA is requested to populate
+ this registry as follows:
+
-Schanzenbach, et al. Expires 13 May 2020 [Page 24]
+
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 25]
Internet-Draft The GNU Name System November 2019
- The registration policy for this sub-registry is "First Come First
- Served", as described in [RFC8126]. IANA is requested to populate
- this registry as follows:
-
Number | Type | Contact | References
---------+-----------------+---------+---------
65536 | PKEY | N/A | [This.I-D]
@@ -1360,7 +1412,7 @@ Internet-Draft The GNU Name System November 2019
65541 | BOX | N/A | [This.I-D]
FIXME We have a lot more?
- Figure 22
+ Figure 17
11. Test Vectors
@@ -1394,18 +1446,18 @@ Internet-Draft The GNU Name System November 2019
d_h :=
01fb61f482c17633
77611c4c2509e0f3
+ 81b0e7e4405c10bd
+ 0017c802f7d32e18
+ q (query key) :=
-Schanzenbach, et al. Expires 13 May 2020 [Page 25]
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 26]
Internet-Draft The GNU Name System November 2019
- 81b0e7e4405c10bd
- 0017c802f7d32e18
-
- q (query key) :=
6fce4deddc5ad681
f4e29a3310767e3b
8b38bc1b276ce2ba
@@ -1450,18 +1502,18 @@ Internet-Draft The GNU Name System November 2019
RRBLOCK :=
055cb070e05fe6de SIGNATURE
ad694a50e5b4dedd
+ b9fdcbdbae004f65
+ afc99ba9c5a3bb54
+ 07e731a34680ee33
+ ae0de7bfeda7d2b7
-Schanzenbach, et al. Expires 13 May 2020 [Page 26]
+Schanzenbach, et al. Expires 13 May 2020 [Page 27]
Internet-Draft The GNU Name System November 2019
- b9fdcbdbae004f65
- afc99ba9c5a3bb54
- 07e731a34680ee33
- ae0de7bfeda7d2b7
8c6b854a008b1b54
10df4f39f5ba9f46____________
8cb514a56c0eaae0 zk_h
@@ -1506,18 +1558,18 @@ Internet-Draft The GNU Name System November 2019
[RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The
Advanced Encryption Standard (AES) Cipher Algorithm in the
+ SNMP User-based Security Model", RFC 3826,
+ DOI 10.17487/RFC3826, June 2004,
+ <https://www.rfc-editor.org/info/rfc3826>.
-Schanzenbach, et al. Expires 13 May 2020 [Page 27]
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 28]
Internet-Draft The GNU Name System November 2019
- SNMP User-based Security Model", RFC 3826,
- DOI 10.17487/RFC3826, June 2004,
- <https://www.rfc-editor.org/info/rfc3826>.
-
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
@@ -1559,13 +1611,17 @@ Internet-Draft The GNU Name System November 2019
[TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A
128-Bit Block Cipher, 1st Edition", March 1999.
- [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based
- Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914,
- August 2016, <https://www.rfc-editor.org/info/rfc7914>.
+ [Argon2] Biryukov, A., Dinu, D., Khovratovich, D., and S.
+ Josefsson, "The memory-hard Argon2 password hash and
+ proof-of-work function", March 2020,
+ <https://datatracker.ietf.org/doc/draft-irtf-cfrg-
+ argon2/>.
-Schanzenbach, et al. Expires 13 May 2020 [Page 28]
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 29]
Internet-Draft The GNU Name System November 2019
@@ -1621,4 +1677,4 @@ Authors' Addresses
-Schanzenbach, et al. Expires 13 May 2020 [Page 29]
+Schanzenbach, et al. Expires 13 May 2020 [Page 30]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -1,19 +1,19 @@
<?xml version='1.0' encoding='utf-8'?>
-<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
-<!ENTITY RFC1034 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml">
-<!ENTITY RFC1035 PUBLIC '' "http://xml2rfc.ietf.org/rfc/bibxml/reference.RFC.1035.xml">
-<!ENTITY RFC2119 PUBLIC '' "http://xml2rfc.ietf.org/rfc/bibxml/reference.RFC.2119.xml">
-<!ENTITY RFC2782 PUBLIC '' "http://xml2rfc.ietf.org/rfc/bibxml/reference.RFC.2782.xml">
-<!ENTITY RFC3629 PUBLIC '' "http://xml2rfc.ietf.org/rfc/bibxml/reference.RFC.3629.xml">
-<!ENTITY RFC3826 PUBLIC '' "http://xml2rfc.ietf.org/rfc/bibxml/reference.RFC.3826.xml">
-<!ENTITY RFC5869 PUBLIC '' "http://xml2rfc.ietf.org/rfc/bibxml/reference.RFC.5869.xml">
-<!ENTITY RFC5890 PUBLIC '' "http://xml2rfc.ietf.org/rfc/bibxml/reference.RFC.5890.xml">
-<!ENTITY RFC5891 PUBLIC '' "http://xml2rfc.ietf.org/rfc/bibxml/reference.RFC.5891.xml">
-<!ENTITY RFC6895 PUBLIC '' "http://xml2rfc.ietf.org/rfc/bibxml/reference.RFC.6895.xml">
-<!ENTITY RFC6979 PUBLIC '' "http://xml2rfc.ietf.org/rfc/bibxml/reference.RFC.6979.xml">
-<!ENTITY RFC7748 PUBLIC '' "http://xml2rfc.ietf.org/rfc/bibxml/reference.RFC.7748.xml">
-<!ENTITY RFC8032 PUBLIC '' "http://xml2rfc.ietf.org/rfc/bibxml/reference.RFC.8032.xml">
-<!ENTITY RFC8126 PUBLIC '' "http://xml2rfc.ietf.org/rfc/bibxml/reference.RFC.8126.xml">
+<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
+<!ENTITY RFC1034 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/bibxml/reference.RFC.1034.xml">
+<!ENTITY RFC1035 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
+<!ENTITY RFC2119 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
+<!ENTITY RFC2782 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
+<!ENTITY RFC3629 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
+<!ENTITY RFC3826 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml">
+<!ENTITY RFC5869 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml">
+<!ENTITY RFC5890 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
+<!ENTITY RFC5891 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5891.xml">
+<!ENTITY RFC6895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml">
+<!ENTITY RFC6979 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml">
+<!ENTITY RFC7748 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7748.xml">
+<!ENTITY RFC8032 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml">
+<!ENTITY RFC8126 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
@@ -1260,7 +1260,8 @@
</dd>
<dt>POW_i</dt>
<dd>
- The POWs calculated as part of the proof-of-work.
+ The POWs calculated as part of the proof-of-work. Each POW_i MUST
+ be unique in the set of POW values.
</dd>
<dt>SIGNATURE</dt>
<dd>
@@ -1298,6 +1299,7 @@
<li>The current time MUST be between TIMESTAMP and
TIMESTAMP+TTL.</li>
<li>The signature MUST match the public key.</li>
+ <li>The set of POW values MUST NOT contain duplicates.</li>
<li>The average number of leading zeroes resulting from the provided
POW values D' MUST be greater than or equal to D.</li>
<li>The actual expiration time TIMESTAMP + (D'-D+1) * 365 days
@@ -1388,10 +1390,34 @@
</section>
<section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name>
- <t>
- TODO
+ <section anchor="security_rev" numbered="true" toc="default">
+ <name>Revocations</name>
+ <t>
+ Revocation payloads do NOT include a 'new' key for key replacement.
+ In inclusion of such a key would have two major disadvantages:
+ </t>
+ <t>
+ If revocation is used after a private key was compromised,
+ allowing key replacement would be dangerous, because if an
+ adversary took over the private key, the adversary could then
+ broadcast a revocation with a key replacement. For the replacement,
+ the compromised owner would have no chance to issue even a
+ revocation. Thus, allowing a revocation message to replace a private
+ key makes dealing with key compromise situations worse.
+ </t>
+ <t>
+ Sometimes, key revocations are used with the objective of changing
+ cryptosystems. Migration to another cryptosystem by replacing keys
+ via a revocation message would only be secure as long as both
+ cryptosystems are still secure against forgery. Such a planned,
+ non-emergency migration to another cryptosystem should be done by
+ running zones for both ciphersystems in parallel for a while. The
+ migration would conclude by revoking the legacy zone key only once
+ it is deemed no longer secure, and hopefully after most users have
+ migrated to the replacement.
</t>
</section>
+ </section>
<section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>
