[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: corrections
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated: corrections |
|
Date: |
Wed, 22 Apr 2020 22:30:49 +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 3534b5e corrections
3534b5e is described below
commit 3534b5e479c7ec728c0c2fef071c750bd71e1664
Author: Martin Schanzenbach <address@hidden>
AuthorDate: Wed Apr 22 22:26:02 2020 +0200
corrections
---
draft-schanzen-gns.html | 362 +++++++++++++++++++++++++++++++----------------
draft-schanzen-gns.txt | 368 ++++++++++++++++++++++++++++--------------------
draft-schanzen-gns.xml | 86 +++++++----
3 files changed, 513 insertions(+), 303 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 57e83a1..132e2ff 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -11,7 +11,7 @@
<meta content="
This document contains the GNU Name System (GNS) technical
specification.
" name="description">
-<meta content="xml2rfc 2.39.0" name="generator">
+<meta content="xml2rfc 2.43.0" name="generator">
<meta content="name systems" name="keyword">
<meta content="draft-schanzen-gns-00" name="ietf.draft">
<link href="draft-schanzen-gns.xml" rel="alternate" type="application/rfc+xml">
@@ -991,7 +991,7 @@ h1#rfcnum {
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
- margin: 0 0 0.25em 0;
+ margin-bottom: 0.25em;
min-height: initial;
}
/* Give aside some styling to set it apart */
@@ -1029,17 +1029,71 @@ aside > p {
margin-bottom: 1em;
}
}
-/*
- The margin-left: 0 on <dd> removes all distinction
- between levels from nested <dl>s. Undo that.
-*/
-dl.olPercent > dd,
-dd {
- margin-left: revert;
-}
/* Avoid narrow tables forcing too narrow table captions, which may render
badly */
table {
min-width: 20em;
+}
+/* ol type a */
+ol.type-a { list-style-type: lower-alpha; }
+ol.type-A { list-style-type: upper-alpha; }
+ol.type-i { list-style-type: lower-roman; }
+ol.type-I { list-style-type: lower-roman; }
+/* Apply the print table and row borders in general, on request from the RPC,
+and increase the contrast between border and odd row background sligthtly */
+table {
+ border: 1px solid #ddd;
+}
+td {
+ border-top: 1px solid #ddd;
+}
+tr:nth-child(2n+1) > td {
+ background-color: #f8f8f8;
+}
+/* Use style rules to govern display of the TOC. */
+@media screen and (max-width: 1023px) {
+ #toc nav { display: none; }
+ #toc.active nav { display: block; }
+}
+/* Add support for keepWithNext */
+.keepWithNext {
+ break-after: avoid-page;
+ break-after: avoid-page;
+}
+/* Add support for keepWithPrevious */
+.keepWithPrevious {
+ break-before: avoid-page;
+}
+/* Change the approach to avoiding breaks inside artwork etc. */
+figure, pre, table, .artwork, .sourcecode {
+ break-before: avoid-page;
+ break-after: auto;
+}
+/* Avoid breaks between <dt> and <dd> */
+dl {
+ break-inside: auto;
+}
+dt {
+ break-before: auto;
+ break-inside: avoid-page;
+ break-after: avoid-page;
+}
+dd {
+ break-before: avoid-page;
+ break-inside: avoid-page;
+ break-after: auto;
+}
+dd.break {
+ margin-bottom: 0;
+ min-height: 0;
+ break-before: auto;
+ break-inside: auto;
+ break-after: auto;
+}
+/* Undo break-before ToC */
+@media print {
+ #toc {
+ break-before: auto;
+ }
}</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
</head>
@@ -1143,16 +1197,16 @@ table {
</h2>
<nav class="toc"><ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1">
- <p id="section-toc.1-1.1.1"><a href="#section-1"
class="xref">1</a>. <a href="#name-introduction"
class="xref">Introduction</a><a href="#section-toc.1-1.1.1"
class="pilcrow">¶</a></p>
+ <p id="section-toc.1-1.1.1" class="keepWithNext"><a
href="#section-1" class="xref">1</a>. <a href="#name-introduction"
class="xref">Introduction</a><a href="#section-toc.1-1.1.1"
class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.2">
- <p id="section-toc.1-1.2.1"><a href="#section-2"
class="xref">2</a>. <a href="#name-zones" class="xref">Zones</a><a
href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
+ <p id="section-toc.1-1.2.1" class="keepWithNext"><a
href="#section-2" class="xref">2</a>. <a href="#name-zones"
class="xref">Zones</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.3">
<p id="section-toc.1-1.3.1"><a href="#section-3"
class="xref">3</a>. <a href="#name-resource-records" class="xref">Resource
Records</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.3.2.1">
- <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1"
class="xref">3.1</a>. <a href="#name-record-types" class="xref">Record
Types</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
+ <p id="section-toc.1-1.3.2.1.1" class="keepWithNext"><a
href="#section-3.1" class="xref">3.1</a>. <a href="#name-record-types"
class="xref">Record Types</a><a href="#section-toc.1-1.3.2.1.1"
class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.3.2.2">
<p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2"
class="xref">3.2</a>. <a href="#name-pkey" class="xref">PKEY</a><a
href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
@@ -1325,20 +1379,24 @@ table {
In GNS, records are signed using a key derived from "d" as described
in
<a href="#publish" class="xref">Section 4</a>.<a
href="#section-2-2.2" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-2-2.3">p</dt>
<dd id="section-2-2.4">
is the prime of edwards25519 as defined in <span>[<a href="#RFC7748"
class="xref">RFC7748</a>]</span>, i.e.
2^255 - 19.<a href="#section-2-2.4" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-2-2.5">B</dt>
<dd id="section-2-2.6">
is the group generator (X(P),Y(P)) of edwards25519 as defined in
<span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>.<a
href="#section-2-2.6" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-2-2.7">L</dt>
<dd id="section-2-2.8">
is the prime-order subgroup of edwards25519 in <span>[<a
href="#RFC7748" class="xref">RFC7748</a>]</span>.<a href="#section-2-2.8"
class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-2-2.9">zk</dt>
<dd id="section-2-2.10">
is the ECDSA public key corresponding to d. It is defined in
@@ -1347,6 +1405,7 @@ table {
The public key is used to uniquely identify a GNS zone and is
referred to
as the "zone key".<a href="#section-2-2.10" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
</dl>
</section>
</div>
@@ -1379,7 +1438,7 @@ table {
+-----+-----+-----+-----+ /
/ /
/ /
- </pre>
+</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure
1</a></figcaption></figure>
</div>
@@ -1391,11 +1450,13 @@ table {
In microseconds since midnight (0 hour), January 1, 1970 in network
byte order.<a href="#section-3-5.2" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-3-5.3">DATA SIZE</dt>
<dd id="section-3-5.4">
denotes the 32-bit size of the DATA field in bytes and in network byte
order.<a href="#section-3-5.4" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-3-5.5">TYPE</dt>
<dd id="section-3-5.6">
is the 32-bit resource record type. This type can be one of the GNS
resource
@@ -1405,16 +1466,19 @@ table {
stored in network byte order. Note that values
below 2^16 are reserved for allocation via IANA (<span>[<a
href="#RFC6895" class="xref">RFC6895</a>]</span>).<a href="#section-3-5.6"
class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-3-5.7">FLAGS</dt>
<dd id="section-3-5.8">
is a 32-bit resource record flags field (see below).<a
href="#section-3-5.8" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-3-5.9">DATA</dt>
<dd id="section-3-5.10">
the variable-length resource record data payload. The contents are
defined
by the
respective type of the resource record.<a href="#section-3-5.10"
class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
</dl>
<p id="section-3-6">
Flags indicate metadata surrounding the resource record. A flag
@@ -1429,7 +1493,7 @@ table {
------+--------+--------+--------+--------+--------+
/ ... | SHADOW | EXPREL | SUPPL | PRIVATE| / |
------+--------+--------+--------+--------+--------+
- </pre>
+</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure
2</a></figcaption></figure>
</div>
@@ -1444,6 +1508,7 @@ table {
values of records into the DHT. This way, future values can propagate
and may be
cached before the transition becomes active.<a href="#section-3-9.2"
class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-3-9.3">EXPREL</dt>
<dd id="section-3-9.4">
The expiration time value of the record is a relative time (still in
microseconds)
@@ -1451,6 +1516,7 @@ table {
for records obtained from the DHT, but might be present when a
resolver looks up
private records of a zone hosted locally.<a href="#section-3-9.4"
class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-3-9.5">
SUPPL
</dt>
@@ -1461,6 +1527,7 @@ table {
may be useful for the application. This flag should only be
encountered
by a resolver for records obtained from the DHT.<a
href="#section-3-9.6" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-3-9.7">PRIVATE</dt>
<dd id="section-3-9.8">
This is a private record of this peer and it should thus not be
@@ -1469,6 +1536,7 @@ table {
Private records should still be considered just like
regular records when resolving labels in local zones.<a
href="#section-3-9.8" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
</dl>
<div id="gnsrecords_numbers">
<section id="section-3.1">
@@ -1503,7 +1571,7 @@ table {
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure
3</a></figcaption></figure>
</div>
@@ -1514,6 +1582,7 @@ table {
<dd id="section-3.2-4.2">
A 256-bit ECDSA zone key.<a href="#section-3.2-4.2"
class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
</dl>
</section>
</div>
@@ -1543,7 +1612,7 @@ table {
/ /
| |
+-----------------------------------------------+
- </pre>
+</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure
4</a></figcaption></figure>
</div>
@@ -1554,6 +1623,7 @@ table {
<dd id="section-3.3-4.2">
The name to continue with in DNS (0-terminated).<a
href="#section-3.3-4.2" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-3.3-4.3">DNS SERVER NAME</dt>
<dd id="section-3.3-4.4">
The DNS server to use. May be an IPv4/IPv6 address in dotted decimal
@@ -1561,6 +1631,7 @@ table {
"+" top-level domain. The value is UTF-8 encoded (also for DNS
names)
and 0-terminated.<a href="#section-3.3-4.4" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
</dl>
</section>
</div>
@@ -1588,7 +1659,7 @@ table {
/ /
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure
5</a></figcaption></figure>
</div>
@@ -1599,6 +1670,7 @@ table {
<dd id="section-3.4-4.2">
A UTF-8 string (which is not 0-terminated) representing the legacy
hostname.<a href="#section-3.4-4.2" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
</dl>
<p id="section-3.4-5">
NOTE: If an application uses a LEHO value in an HTTP request header
@@ -1633,7 +1705,7 @@ table {
/ /
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure
6</a></figcaption></figure>
</div>
@@ -1645,6 +1717,7 @@ table {
A UTF-8 string (which is not 0-terminated) representing the
preferred
label of the zone. This string MUST NOT include a "." character.<a
href="#section-3.5-4.2" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
</dl>
</section>
</div>
@@ -1679,7 +1752,7 @@ table {
/ /
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure
7</a></figcaption></figure>
</div>
@@ -1690,20 +1763,24 @@ table {
<dd id="section-3.6-4.2">
the 16-bit protocol number, e.g. 6 for tcp. In network byte
order.<a href="#section-3.6-4.2" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-3.6-4.3">SVC</dt>
<dd id="section-3.6-4.4">
the 16-bit service value of the boxed record, i.e. the port number.
In network byte order.<a href="#section-3.6-4.4"
class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-3.6-4.5">TYPE</dt>
<dd id="section-3.6-4.6">
is the 32-bit record type of the boxed record. In network byte
order.<a href="#section-3.6-4.6" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-3.6-4.7">RECORD DATA</dt>
<dd id="section-3.6-4.8">
is a variable length field containing the "DATA" format of TYPE as
defined for the respective TYPE in DNS.<a href="#section-3.6-4.8"
class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
</dl>
</section>
</div>
@@ -1731,7 +1808,7 @@ table {
/ /
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+</pre>
</div>
<figcaption><a href="#figure-8" class="selfRef">Figure
8</a></figcaption></figure>
</div>
@@ -1743,16 +1820,19 @@ table {
is a 256-bit EdDSA public key identifying the peer hosting the
service.<a href="#section-3.7-4.2" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-3.7-4.3">PROTO</dt>
<dd id="section-3.7-4.4">
the 16-bit protocol number, e.g. 6 for TCP. In network byte
order.<a href="#section-3.7-4.4" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-3.7-4.5">SERVICE NAME</dt>
<dd id="section-3.7-4.6">
a shared secret used to identify the service at the hosting peer,
used to derive the port number requird to connect to the service.
The service name MUST be a 0-terminated UTF-8 string.<a
href="#section-3.7-4.6" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
</dl>
</section>
</div>
@@ -1785,7 +1865,7 @@ table {
d_h := h * d mod L
zk_h := h mod L * zk
q := SHA512 (zk_h)
- </pre><a href="#section-4.1-2" class="pilcrow">¶</a>
+</pre><a href="#section-4.1-2" class="pilcrow">¶</a>
</div>
<p id="section-4.1-3">
We use a hash-based key derivation function (HKDF) as defined in
@@ -1798,33 +1878,40 @@ table {
"key-derivation" as salt and the public zone key "zk" as initial
keying material.<a href="#section-4.1-4.2" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-4.1-4.3">h</dt>
<dd id="section-4.1-4.4">
is the 512-bit HKDF expansion result. The expansion info input is a
concatenation of the label and string "gns".<a
href="#section-4.1-4.4" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-4.1-4.5">d</dt>
<dd id="section-4.1-4.6">
is the 256-bit private zone key as defined in <a href="#zones"
class="xref">Section 2</a>.<a href="#section-4.1-4.6" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-4.1-4.7">label</dt>
<dd id="section-4.1-4.8">
is a UTF-8 string under which the resource records are published.<a
href="#section-4.1-4.8" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-4.1-4.9">d_h</dt>
<dd id="section-4.1-4.10">
is a 256-bit private key derived from the "d" using the
keying material "h".<a href="#section-4.1-4.10"
class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-4.1-4.11">zk_h</dt>
<dd id="section-4.1-4.12">
is a 256-bit public key derived from the zone key "zk" using the
keying material "h".<a href="#section-4.1-4.12"
class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-4.1-4.13">L</dt>
<dd id="section-4.1-4.14">
is the prime-order subgroup as defined in <a href="#zones"
class="xref">Section 2</a>.<a href="#section-4.1-4.14" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-4.1-4.15">q</dt>
<dd id="section-4.1-4.16">
Is the 512-bit DHT key under which the resource records block is
@@ -1832,6 +1919,7 @@ table {
It is the SHA512 hash over the public key "zk_h" corresponding to
the
derived private key "d_h".<a href="#section-4.1-4.16"
class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
</dl>
<p id="section-4.1-5">
We point out that the multiplication of "zk" with "h" is a point
multiplication,
@@ -1882,7 +1970,7 @@ table {
/ /
/ |
+-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+</pre>
</div>
<figcaption><a href="#figure-9" class="selfRef">Figure
9</a></figcaption></figure>
</div>
@@ -1896,12 +1984,14 @@ table {
The signature is created using the derived private key "d_h" (see
<a href="#publish" class="xref">Section 4</a>).<a
href="#section-4.2-4.2" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-4.2-4.3">PUBLIC KEY</dt>
<dd id="section-4.2-4.4">
is the 256-bit public key "zk_h" 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-4.2-4.4" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-4.2-4.5">SIZE</dt>
<dd id="section-4.2-4.6">
A 32-bit value containing the length of the signed data following
the
@@ -1912,11 +2002,13 @@ table {
size significantly below 4 GB. However, a minimum block size of
62 kilobytes MUST be supported.<a href="#section-4.2-4.6"
class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<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>
+<dd class="break"></dd>
<dt id="section-4.2-4.9">EXPIRATION</dt>
<dd id="section-4.2-4.10">
Specifies when the RRBLOCK expires and the encrypted block
@@ -1931,10 +2023,12 @@ table {
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>
+<dd class="break"></dd>
<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 SIZE - 16.<a
href="#section-4.2-4.12" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
</dl>
</section>
</div>
@@ -1974,7 +2068,7 @@ table {
+-----------------------+ /
/ PADDING /
/ /
- </pre>
+</pre>
</div>
<figcaption><a href="#figure-10" class="selfRef">Figure
10</a></figcaption></figure>
</div>
@@ -1986,6 +2080,7 @@ table {
records which are
following after this field in network byte order.<a
href="#section-4.3-4.2" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-4.3-4.3">EXPIRATION, DATA SIZE, TYPE, FLAGS and DATA</dt>
<dd id="section-4.3-4.4">
These fields were defined
@@ -1993,6 +2088,7 @@ table {
There MUST be a total of RR COUNT of these resource records
present.<a href="#section-4.3-4.4" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-4.3-4.5">PADDING</dt>
<dd id="section-4.3-4.6">
The padding MUST contain the value 0 in all octets.
@@ -2002,6 +2098,7 @@ table {
are never padded. Note that a record set with a PKEY record MUST NOT
contain other records.<a href="#section-4.3-4.6"
class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
</dl>
<p id="section-4.3-5">
The symmetric keys and initialization vectors are derived from the
@@ -2014,7 +2111,7 @@ table {
PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
K := HKDF-Expand (PRK_k, label, 512 / 8);
IV := HKDF-Expand (PRK_iv, label, 256 / 8)
- </pre><a href="#section-4.3-6" class="pilcrow">¶</a>
+</pre><a href="#section-4.3-6" class="pilcrow">¶</a>
</div>
<p id="section-4.3-7">
HKDF is a hash-based key derivation function as defined in
@@ -2041,7 +2138,7 @@ table {
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+</pre>
</div>
<figcaption><a href="#figure-11" class="selfRef">Figure
11</a></figcaption></figure>
</div>
@@ -2060,7 +2157,7 @@ table {
| TWOFISH IV |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+</pre>
</div>
<figcaption><a href="#figure-12" class="selfRef">Figure
12</a></figcaption></figure>
</div>
@@ -2074,7 +2171,7 @@ table {
TWOFISH(K[32:63], IV[16:31], BDATA))
BDATA := TWOFISH(K[32:63], IV[16:31],
AES(K[0:31], IV[0:15], RDATA))
- </pre><a href="#section-4.3-12" class="pilcrow">¶</a>
+</pre><a href="#section-4.3-12" class="pilcrow">¶</a>
</div>
</section>
</div>
@@ -2128,7 +2225,7 @@ table {
is empty, it is interpreted as the apex label "@".<a
href="#section-6.1-1" class="pilcrow">¶</a></p>
<p id="section-6.1-2">
From here, the following steps are recursively executed, in
order:<a href="#section-6.1-2" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal" id="section-6.1-3">
+<ol start="1" type="1" class="normal type-1" id="section-6.1-3">
<li id="section-6.1-3.1">Extract the right-most label from the name
to look up.<a href="#section-6.1-3.1" class="pilcrow">¶</a>
</li>
<li id="section-6.1-3.2">Calculate q using the label and zk as defined in
@@ -2159,7 +2256,7 @@ table {
that the RRBLOCK has been cryptographically verified and decrypted.
At this point, we must first determine if we have received a valid
record set in the context of the name we are trying to resolve:<a
href="#section-6.2-1" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal" id="section-6.2-2">
+<ol start="1" type="1" class="normal type-1" id="section-6.2-2">
<li id="section-6.2-2.1">
Case 1:
If the remainder of the name to resolve is empty and the record set
@@ -2346,7 +2443,7 @@ table {
Result:
A: 1.2.3.4
NICK: eve
- </pre>
+</pre>
</div>
<figcaption><a href="#figure-13" class="selfRef">Figure
13</a></figcaption></figure>
<p id="section-6.2.6-4">
@@ -2363,7 +2460,7 @@ table {
Result:
A: 1.2.3.4
NICK: john (Supplemental)
- </pre>
+</pre>
</div>
<figcaption><a href="#figure-14" class="selfRef">Figure
14</a></figcaption></figure>
<p id="section-6.2.6-6">
@@ -2394,13 +2491,15 @@ table {
published.
This object MUST be signed using the private zone key.
The revocation object is flooded in the overlay network. To prevent
- flooding attacks, the revocation message MUST contain a proof-of-work.
- The revocation message including the proof-of-work MAY be calculated
+ flooding attacks, the revocation message MUST contain a proof of work
+ (PoW).
+ The revocation message including the PoW 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, "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>
+ Derivation Function as defined in <span>[<a href="#Argon2"
class="xref">Argon2</a>]</span>. For the
+ PoW calculations the algorithm is instantiated with the
+ following parameters:<a href="#section-7-3" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-7-4">
<pre>
S := "gnunet-revocation-proof-of-work" /* Salt */
@@ -2411,10 +2510,10 @@ table {
v := 0x13 /* Version */
y := 0 /* Type (Argon2d) */
X, K is unused
- </pre><a href="#section-7-4" class="pilcrow">¶</a>
+</pre><a href="#section-7-4" class="pilcrow">¶</a>
</div>
<p id="section-7-5">
- The following is the message string "P" on which the proof-of work is
+ The following is the message string "P" on which the PoW is
calculated:<a href="#section-7-5" class="pilcrow">¶</a></p>
<div id="figure_revocation">
<figure id="figure-15">
@@ -2431,7 +2530,7 @@ table {
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+</pre>
</div>
<figcaption><a href="#figure-15" class="selfRef">Figure
15</a></figcaption></figure>
</div>
@@ -2439,29 +2538,32 @@ table {
<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>
+ A 64-bit solution to the PoW.<a href="#section-7-8.2"
class="pilcrow">¶</a>
</dd>
+<dd class="break"></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>
+<dd class="break"></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.
+ which is revoked and corresponds to the key used in the PoW.
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>
+<dd class="break"></dd>
</dl>
<p id="section-7-9">
- Traditionally, proof-of-work schemes require to find a "POW" such that
+ Traditionally, PoW 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.
+ D is then referred to as the "difficulty" of the PoW.
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
+ PoW, 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
@@ -2472,15 +2574,21 @@ table {
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">
- The paraneters are defined as follows:<a href="#section-7-11"
class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal" id="section-7-12">
- <li id="section-7-12.1">Z: The number of PoWs required is fixed at
32.<a href="#section-7-12.1" class="pilcrow">¶</a>
-</li>
-<li id="section-7-12.2">D: The difficulty is fixed at 25.<a
href="#section-7-12.2" class="pilcrow">¶</a>
-</li>
-<li id="section-7-12.3">EPOCH: A single epoch is fixed at 365 days.<a
href="#section-7-12.3" class="pilcrow">¶</a>
-</li>
-</ol>
+ The parameters are defined as follows:<a href="#section-7-11"
class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-7-12">
+ <dt id="section-7-12.1">Z</dt>
+<dd id="section-7-12.2">The number of PoWs required is fixed at 32.<a
href="#section-7-12.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-7-12.3">D</dt>
+<dd id="section-7-12.4">The difficulty is fixed at 25.<a
href="#section-7-12.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-7-12.5">EPOCH</dt>
+<dd id="section-7-12.6">A single epoch is fixed at 365 days.<a
href="#section-7-12.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
<p id="section-7-13">
Given that proof has been found, a revocation data object is defined
as follows:<a href="#section-7-13" class="pilcrow">¶</a></p>
@@ -2509,14 +2617,12 @@ table {
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- | SIZE (0x24) | PURPOSE (0x03) |
- +-----+-----+-----+-----+-----+-----+-----+-----+
| PUBLIC KEY |
| |
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+</pre>
</div>
<figcaption><a href="#figure-16" class="selfRef">Figure
16</a></figcaption></figure>
</div>
@@ -2528,45 +2634,82 @@ table {
In microseconds since midnight (0 hour), January 1, 1970 in network
byte order.<a href="#section-7-16.2" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-7-16.3">TTL</dt>
<dd id="section-7-16.4">
denotes the relative 64-bit time to live of of the record in
microseconds also in network byte order. This field is informational
- for a verifier. The verifier may discard revocation of the TTL
+ for a verifier. The verifier may discard revocation if the TTL
indicates that it is already expired. However, the actual TTL of the
revocation must be determined by examining the leading zeros in the
proof of work calculation.<a href="#section-7-16.4"
class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-7-16.5">POW_i</dt>
<dd id="section-7-16.6">
- The POWs calculated as part of the proof-of-work. Each POW_i MUST
+ The values calculated as part of the PoW. Each POW_i MUST
be unique in the set of POW values.<a href="#section-7-16.6"
class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
<dt id="section-7-16.7">SIGNATURE</dt>
<dd id="section-7-16.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.
+ which is revoked and corresponds to the key used in the PoW.
The signature is created using the private zone key "d" (see
<a href="#zones" class="xref">Section 2</a>).<a
href="#section-7-16.8" class="pilcrow">¶</a>
</dd>
-<dt id="section-7-16.9">SIZE</dt>
+<dd class="break"></dd>
+<dt id="section-7-16.9">PUBLIC KEY</dt>
<dd id="section-7-16.10">
+ 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-16.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-7-17">
+ The signature over the public key covers a 32 bit pseudo header
+ conceptually prefixed to the public key. The pseudo header includes
+ the key length and signature purpose:<a href="#section-7-17"
class="pilcrow">¶</a></p>
+<div id="figure_revsigwithpseudo">
+<figure id="figure-17">
+ <div class="artwork art-text alignLeft" id="section-7-18.1">
+<pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | SIZE (0x30) | PURPOSE (0x03) |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TIMESTAMP |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+</pre>
+</div>
+<figcaption><a href="#figure-17" class="selfRef">Figure
17</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">SIZE</dt>
+<dd id="section-7-20.2">
A 32-bit value containing the length of the signed data in bytes
- (36 bytes) in network byte order.<a href="#section-7-16.10"
class="pilcrow">¶</a>
+ (48 bytes) in network byte order.<a href="#section-7-20.2"
class="pilcrow">¶</a>
</dd>
-<dt id="section-7-16.11">PURPOSE</dt>
-<dd id="section-7-16.12">
+<dd class="break"></dd>
+<dt id="section-7-20.3">PURPOSE</dt>
+<dd id="section-7-20.4">
A 32-bit signature purpose flag. This field MUST be 3 (in network
- byte order).<a href="#section-7-16.12" class="pilcrow">¶</a>
+ byte order).<a href="#section-7-20.4" class="pilcrow">¶</a>
</dd>
-<dt id="section-7-16.13">PUBLIC KEY</dt>
-<dd id="section-7-16.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-16.14" class="pilcrow">¶</a>
+<dd class="break"></dd>
+<dt id="section-7-20.5">PUBLIC KEY / TIMESTAMP</dt>
+<dd id="section-7-20.6">Both values as defined in the revocation data object
above.<a href="#section-7-20.6" class="pilcrow">¶</a>
</dd>
+<dd class="break"></dd>
</dl>
<div id="revocation_verification">
<section id="section-7.1">
@@ -2576,7 +2719,7 @@ table {
<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">
+<ol start="1" type="1" class="normal type-1" 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>
@@ -2637,7 +2780,7 @@ table {
Example name: www.example.<Base32(zk)>
=> Root zone: zk
=> Name to resolve from root zone: www.example
- </pre><a href="#section-8-5" class="pilcrow">¶</a>
+</pre><a href="#section-8-5" class="pilcrow">¶</a>
</div>
<p id="section-8-6">
In GNS, users MAY own and manage their own zones.
@@ -2657,7 +2800,7 @@ table {
...
=> Entry zone: zk1
=> Name to resolve from entry zone: www.example
- </pre><a href="#section-8-7" class="pilcrow">¶</a>
+</pre><a href="#section-8-7" class="pilcrow">¶</a>
</div>
<p id="section-8-8">
Finally, additional "suffix to zone" mappings MAY be configured.
@@ -2679,7 +2822,7 @@ table {
...
=> Entry zone: zk1
=> Name to resolve from entry zone: www
- </pre><a href="#section-8-9" class="pilcrow">¶</a>
+</pre><a href="#section-8-9" class="pilcrow">¶</a>
</div>
</section>
</div>
@@ -2744,7 +2887,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-17">
+<figure id="figure-18">
<div class="artwork art-text alignLeft" id="section-10-4.1">
<pre>
Number | Type | Contact | References
@@ -2756,9 +2899,9 @@ The registry shall record for each entry:<a
href="#section-10-1" class="pilcrow"
65540 | GNS2DNS | N/A | [This.I-D]
65541 | BOX | N/A | [This.I-D]
FIXME We have a lot more?
- </pre>
+</pre>
</div>
-<figcaption><a href="#figure-17" class="selfRef">Figure
17</a></figcaption></figure>
+<figcaption><a href="#figure-18" class="selfRef">Figure
18</a></figcaption></figure>
</div>
</section>
</div>
@@ -2867,7 +3010,7 @@ The registry shall record for each entry:<a
href="#section-10-1" class="pilcrow"
642920eee8e7a65a
001fd19a6406a721
713f0a0d
- </pre><a href="#section-11-2" class="pilcrow">¶</a>
+</pre><a href="#section-11-2" class="pilcrow">¶</a>
</div>
</section>
<section id="section-12">
@@ -2878,51 +3021,67 @@ The registry shall record for each entry:<a
href="#section-10-1" class="pilcrow"
<dt id="RFC1034">[RFC1034]</dt>
<dd>
<span class="refAuthor">Mockapetris, P.</span>, <span class="refTitle">"Domain
names - concepts and facilities"</span>, <span class="seriesInfo">STD
13</span>, <span class="seriesInfo">RFC 1034</span>, <span
class="seriesInfo">DOI 10.17487/RFC1034</span>, <time
datetime="1987-11">November 1987</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc1034";>https://www.rfc-editor.org/info/rfc1034</a>></span>.
</dd>
+<dd class="break"></dd>
<dt id="RFC1035">[RFC1035]</dt>
<dd>
<span class="refAuthor">Mockapetris, P.</span>, <span class="refTitle">"Domain
names - implementation and specification"</span>, <span class="seriesInfo">STD
13</span>, <span class="seriesInfo">RFC 1035</span>, <span
class="seriesInfo">DOI 10.17487/RFC1035</span>, <time
datetime="1987-11">November 1987</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc1035";>https://www.rfc-editor.org/info/rfc1035</a>></span>.
</dd>
+<dd class="break"></dd>
<dt id="RFC2782">[RFC2782]</dt>
<dd>
<span class="refAuthor">Gulbrandsen, A.</span><span class="refAuthor">, Vixie,
P.</span><span class="refAuthor">, and L. Esibov</span>, <span
class="refTitle">"A DNS RR for specifying the location of services (DNS
SRV)"</span>, <span class="seriesInfo">RFC 2782</span>, <span
class="seriesInfo">DOI 10.17487/RFC2782</span>, <time
datetime="2000-02">February 2000</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc2782";>https://www.rfc-editor.org/info/rfc2782</a>></span>.
</dd>
+<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
<dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words
for use in RFCs to Indicate Requirement Levels"</span>, <span
class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>,
<span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time
datetime="1997-03">March 1997</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc2119";>https://www.rfc-editor.org/info/rfc2119</a>></span>.
</dd>
+<dd class="break"></dd>
<dt id="RFC3629">[RFC3629]</dt>
<dd>
<span class="refAuthor">Yergeau, F.</span>, <span class="refTitle">"UTF-8, a
transformation format of ISO 10646"</span>, <span class="seriesInfo">STD
63</span>, <span class="seriesInfo">RFC 3629</span>, <span
class="seriesInfo">DOI 10.17487/RFC3629</span>, <time
datetime="2003-11">November 2003</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc3629";>https://www.rfc-editor.org/info/rfc3629</a>></span>.
</dd>
+<dd class="break"></dd>
<dt id="RFC3826">[RFC3826]</dt>
<dd>
<span class="refAuthor">Blumenthal, U.</span><span class="refAuthor">, Maino,
F.</span><span class="refAuthor">, and K. McCloghrie</span>, <span
class="refTitle">"The Advanced Encryption Standard (AES) Cipher Algorithm in
the SNMP User-based Security Model"</span>, <span class="seriesInfo">RFC
3826</span>, <span class="seriesInfo">DOI 10.17487/RFC3826</span>, <time
datetime="2004-06">June 2004</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc3826";>https://www.rfc-editor.org/ [...]
+<dd class="break"></dd>
<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)"</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>
+<dd class="break"></dd>
<dt id="RFC5890">[RFC5890]</dt>
<dd>
<span class="refAuthor">Klensin, J.</span>, <span
class="refTitle">"Internationalized Domain Names for Applications (IDNA):
Definitions and Document Framework"</span>, <span class="seriesInfo">RFC
5890</span>, <span class="seriesInfo">DOI 10.17487/RFC5890</span>, <time
datetime="2010-08">August 2010</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc5890";>https://www.rfc-editor.org/info/rfc5890</a>></span>.
</dd>
+<dd class="break"></dd>
<dt id="RFC5891">[RFC5891]</dt>
<dd>
<span class="refAuthor">Klensin, J.</span>, <span
class="refTitle">"Internationalized Domain Names in Applications (IDNA):
Protocol"</span>, <span class="seriesInfo">RFC 5891</span>, <span
class="seriesInfo">DOI 10.17487/RFC5891</span>, <time datetime="2010-08">August
2010</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc5891";>https://www.rfc-editor.org/info/rfc5891</a>></span>.
</dd>
+<dd class="break"></dd>
<dt id="RFC6895">[RFC6895]</dt>
<dd>
<span class="refAuthor">Eastlake 3rd, D.</span>, <span
class="refTitle">"Domain Name System (DNS) IANA Considerations"</span>, <span
class="seriesInfo">BCP 42</span>, <span class="seriesInfo">RFC 6895</span>,
<span class="seriesInfo">DOI 10.17487/RFC6895</span>, <time
datetime="2013-04">April 2013</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc6895";>https://www.rfc-editor.org/info/rfc6895</a>></span>.
</dd>
+<dd class="break"></dd>
<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>
+<dd class="break"></dd>
<dt id="RFC7748">[RFC7748]</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>
+<dd class="break"></dd>
<dt id="RFC8032">[RFC8032]</dt>
<dd>
<span class="refAuthor">Josefsson, S.</span><span class="refAuthor"> and I.
Liusvaara</span>, <span class="refTitle">"Edwards-Curve Digital Signature
Algorithm (EdDSA)"</span>, <span class="seriesInfo">RFC 8032</span>, <span
class="seriesInfo">DOI 10.17487/RFC8032</span>, <time
datetime="2017-01">January 2017</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc8032";>https://www.rfc-editor.org/info/rfc8032</a>></span>.
</dd>
+<dd class="break"></dd>
<dt id="RFC8126">[RFC8126]</dt>
<dd>
<span class="refAuthor">Cotton, M.</span><span class="refAuthor">, Leiba,
B.</span><span class="refAuthor">, and T. Narten</span>, <span
class="refTitle">"Guidelines for Writing an IANA Considerations Section in
RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span
class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI
10.17487/RFC8126</span>, <time datetime="2017-06">June 2017</time>,
<span><<a
href="https://www.rfc-editor.org/info/rfc8126";>https://www.rfc-editor.org/ [...]
+<dd class="break"></dd>
<dt id="TWOFISH">[TWOFISH]</dt>
<dd>
<span class="refAuthor">Schneier, B.</span>, <span class="refTitle">"The
Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition"</span>,
<time datetime="1999-03">March 1999</time>. </dd>
+<dd class="break"></dd>
<dt id="Argon2">[Argon2]</dt>
<dd>
<span class="refAuthor">Biryukov, A.</span><span class="refAuthor">, Dinu,
D.</span><span class="refAuthor">, Khovratovich, D.</span><span
class="refAuthor">, and S. Josefsson</span>, <span class="refTitle">"The
memory-hard Argon2 password hash and proof-of-work function"</span>, <time
datetime="2020-03">March 2020</time>, <span><<a
href="https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/";>https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/</a>></span>.
</dd>
+<dd class="break"></dd>
</dl>
</section>
<div id="authors-addresses">
@@ -2947,8 +3106,7 @@ The registry shall record for each entry:<a
href="#section-10-1" class="pilcrow"
<div dir="auto" class="left"><span class="fn nameRole">Christian
Grothoff</span></div>
<div dir="auto" class="left"><span class="org">Berner
Fachhochschule</span></div>
<div dir="auto" class="left"><span class="street-address">Hoeheweg
80</span></div>
-<div dir="auto" class="left">
-<span class="postal-code">2501</span> <span class="locality">Biel/Bienne</span>
+<div dir="auto" class="left">CH-<span class="postal-code">2501</span> <span
class="locality">Biel/Bienne</span>
</div>
<div dir="auto" class="left"><span
class="country-name">Switzerland</span></div>
<div class="email">
@@ -2971,45 +3129,13 @@ The registry shall record for each entry:<a
href="#section-10-1" class="pilcrow"
</address>
</section>
</div>
-<script>var toc = document.getElementById("toc");
-var tocToggle = toc.querySelector("h2");
-var tocNav = toc.querySelector("nav");
-
-// mobile menu toggle
-tocToggle.onclick = function(event) {
- if (window.innerWidth < 1024) {
- var tocNavDisplay = tocNav.currentStyle ? tocNav.currentStyle.display :
getComputedStyle(tocNav, null).display;
- if (tocNavDisplay == "none") {
- tocNav.style.display = "block";
- } else {
- tocNav.style.display = "none";
- }
- }
-}
-
-// toc anchor scroll to anchor
-tocNav.addEventListener("click", function (event) {
- event.preventDefault();
- if (event.target.nodeName == 'A') {
- if (window.innerWidth < 1024) {
- tocNav.style.display = "none";
- }
- var href = event.target.getAttribute("href");
- var anchorId = href.substr(1);
- var anchor = document.getElementById(anchorId);
- anchor.scrollIntoView(true);
- window.history.pushState("","",href);
- }
+<script>const toc = document.getElementById("toc");
+toc.querySelector("h2").addEventListener("click", e => {
+ toc.classList.toggle("active");
+});
+toc.querySelector("nav").addEventListener("click", e => {
+ toc.classList.remove("active");
});
-
-// switch toc mode when window resized
-window.onresize = function () {
- if (window.innerWidth < 1024) {
- tocNav.style.display = "none";
- } else {
- tocNav.style.display = "block";
- }
-}
</script>
</body>
</html>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index 7b0fddf..42ab675 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -82,14 +82,14 @@ Table of Contents
6.2.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.3. CNAME . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 6.2.5. VPN . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 6.2.5. VPN . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2.6. NICK . . . . . . . . . . . . . . . . . . . . . . . . 19
- 7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 19
+ 7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Verification . . . . . . . . . . . . . . . . . . . . . . 23
- 8. Determining the Root Zone and Zone Governance . . . . . . . . 23
+ 8. Determining the Root Zone and Zone Governance . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9.1. Revocations . . . . . . . . . . . . . . . . . . . . . . . 25
- 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
+ 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 26
12. Normative References . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
@@ -214,10 +214,10 @@ Internet-Draft The GNU Name System
November 2019
DATA SIZE denotes the 32-bit size of the DATA field in bytes and in
network byte order.
- TYPE is the 32-bit resource record type. This type can be one of
- 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
+
+
+
+
@@ -226,6 +226,10 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 4]
Internet-Draft The GNU Name System November 2019
+ TYPE is the 32-bit resource record type. This type can be one of
+ 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]).
@@ -268,11 +272,7 @@ Internet-Draft The GNU Name System
November 2019
should only be encountered by a resolver for records obtained from
the DHT.
- PRIVATE This is a private record of this peer and it should thus not
- be published in the DHT. Thus, this flag should never be
- encountered by a resolver for records obtained from the DHT.
- Private records should still be considered just like regular
- records when resolving labels in local zones.
+
@@ -282,6 +282,12 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 5]
Internet-Draft The GNU Name System November 2019
+ PRIVATE This is a private record of this peer and it should thus not
+ be published in the DHT. Thus, this flag should never be
+ encountered by a resolver for records obtained from the DHT.
+ Private records should still be considered just like regular
+ records when resolving labels in local zones.
+
3.1. Record Types
A registry of GNS Record Types is described in Section 10. The
@@ -327,12 +333,6 @@ Internet-Draft The GNU Name System
November 2019
-
-
-
-
-
-
Schanzenbach, et al. Expires 13 May 2020 [Page 6]
Internet-Draft The GNU Name System November 2019
@@ -938,14 +938,14 @@ Internet-Draft The GNU Name System
November 2019
resolution fails and an emtpy record set is returned as the record
set is invalid.
- Once the IP addresses of the DNS servers have been determined, the
- DNS name from the GNS2DNS record is appended to the remainder of the
- name to be resolved, and resolved by querying the DNS name server(s).
- As the DNS servers specified are possibly authoritative DNS servers,
- the GNS resolver MUST support recursive resolution and MUST NOT
- delegate this to the authoritative DNS servers. The first successful
- recursive name resolution result is returned to the client. In
- addition, the resolver returns the queried DNS name as a supplemental
+
+
+
+
+
+
+
+
@@ -954,6 +954,14 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 17]
Internet-Draft The GNU Name System November 2019
+ Once the IP addresses of the DNS servers have been determined, the
+ DNS name from the GNS2DNS record is appended to the remainder of the
+ name to be resolved, and resolved by querying the DNS name server(s).
+ As the DNS servers specified are possibly authoritative DNS servers,
+ the GNS resolver MUST support recursive resolution and MUST NOT
+ delegate this to the authoritative DNS servers. The first successful
+ recursive name resolution result is returned to the client. In
+ addition, the resolver returns the queried DNS name as a supplemental
LEHO record (Section 3.4) with a relative expiration time of one
hour.
@@ -993,14 +1001,6 @@ Internet-Draft The GNU Name System
November 2019
do not require a separate network request, and TLSA records become
inseparable from the corresponding address records.
-6.2.5. VPN
-
- At the end of the recursion, if the queried record type is either A
- or AAAA and the retrieved record set contains at least one VPN
- record, the resolver SHOULD open a tunnel and return the IPv4 or IPv6
- tunnel address, respectively. The type of tunnel depends on the
- contents of the VPN record data. The VPN record MUST be returned if
- the resolver implementation does not support setting up a tunnnel.
@@ -1010,6 +1010,15 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 18]
Internet-Draft The GNU Name System November 2019
+6.2.5. VPN
+
+ At the end of the recursion, if the queried record type is either A
+ or AAAA and the retrieved record set contains at least one VPN
+ record, the resolver SHOULD open a tunnel and return the IPv4 or IPv6
+ tunnel address, respectively. The type of tunnel depends on the
+ contents of the VPN record data. The VPN record MUST be returned if
+ the resolver implementation does not support setting up a tunnnel.
+
6.2.6. NICK
NIICK records are only relevant to the recursive resolver if the
@@ -1044,6 +1053,19 @@ Internet-Draft The GNU Name System
November 2019
Figure 14
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 19]
+
+Internet-Draft The GNU Name System November 2019
+
+
In this case, the NICK record is marked as supplemental. This means
that the NICK record belongs to the zone "doe" and is published under
the label "alice" along with an A record. The NICK record should be
@@ -1058,24 +1080,16 @@ Internet-Draft The GNU Name System
November 2019
key has been revoked. If the zone key was revoked, the resolution
MUST fail with an empty result set.
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 19]
-
-Internet-Draft The GNU Name System November 2019
-
-
In order to revoke a zone key, a signed revocation object SHOULD be
published. This object MUST be signed using the private zone key.
The revocation object is flooded in the overlay network. To prevent
- flooding attacks, the revocation message MUST contain a proof-of-
- work. The revocation message including the proof-of-work MAY be
- calculated ahead of time to support timely revocation.
+ flooding attacks, the revocation message MUST contain a proof of work
+ (PoW). The revocation message including the PoW MAY be calculated
+ ahead of time to support timely revocation.
For all occurences below, "Argon2d" is the Password-based Key
- Derivation Function as defined in [Argon2] with the following fixed
- parameters:
+ Derivation Function as defined in [Argon2]. For the PoW calculations
+ the algorithm is instantiated with the following parameters:
S := "gnunet-revocation-proof-of-work" /* Salt */
t := 3 /* Iterations */
@@ -1086,7 +1100,7 @@ Internet-Draft The GNU Name System
November 2019
y := 0 /* Type (Argon2d) */
X, K is unused
- The following is the message string "P" on which the proof-of work is
+ The following is the message string "P" on which the PoW is
calculated:
0 8 16 24 32 40 48 56
@@ -1101,11 +1115,18 @@ Internet-Draft The GNU Name System
November 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 20]
+
+Internet-Draft The GNU Name System November 2019
+
+
Figure 15
where:
- POW A 64-bit solution to the proof of work.
+ POW A 64-bit solution to the PoW.
TIMESTAMP denotes the absolute 64-bit expiration date of the record.
In microseconds since midnight (0 hour), January 1, 1970 in
@@ -1113,24 +1134,14 @@ Internet-Draft The GNU Name System
November 2019
PUBLIC KEY 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 PoW. The signature is created
+ using the private zone key "d" (see Section 2).
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 20]
-
-Internet-Draft The GNU Name System November 2019
-
-
- 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.
+ Traditionally, PoW 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 PoW. In order to reduce the variance in
+ time it takes to calculate the PoW, 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
@@ -1140,13 +1151,13 @@ Internet-Draft The GNU Name System
November 2019
Consequently, by calculating a more difficult PoW, the lifetime of
the proof can be increased on demand by the zone owner.
- The paraneters are defined as follows:
+ The parameters are defined as follows:
- 1. Z: The number of PoWs required is fixed at 32.
+ Z The number of PoWs required is fixed at 32.
- 2. D: The difficulty is fixed at 25.
+ D The difficulty is fixed at 25.
- 3. EPOCH: A single epoch is fixed at 365 days.
+ EPOCH A single epoch is fixed at 365 days.
Given that proof has been found, a revocation data object is defined
as follows:
@@ -1159,17 +1170,6 @@ Internet-Draft The GNU Name System
November 2019
-
-
-
-
-
-
-
-
-
-
-
@@ -1199,8 +1199,6 @@ Internet-Draft The GNU Name System
November 2019
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- | SIZE (0x24) | PURPOSE (0x03) |
- +-----+-----+-----+-----+-----+-----+-----+-----+
| PUBLIC KEY |
| |
| |
@@ -1218,12 +1216,14 @@ Internet-Draft The GNU Name System
November 2019
TTL denotes the relative 64-bit time to live of of the record in
microseconds also in network byte order. This field is
informational for a verifier. The verifier may discard revocation
- of the TTL indicates that it is already expired. However, the
+ if the TTL indicates that it is already expired. However, the
actual TTL of the revocation must be determined by examining the
leading zeros in the proof of work calculation.
- POW_i The POWs calculated as part of the proof-of-work. Each POW_i
- MUST be unique in the set of POW values.
+ POW_i The values calculated as part of the PoW. Each POW_i MUST be
+ unique in the set of POW values.
+
+
@@ -1236,18 +1236,41 @@ Internet-Draft The GNU Name System
November 2019
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).
+ corresponds to the key used in the PoW. 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.
+
+ The signature over the public key covers a 32 bit pseudo 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 (0x30) | PURPOSE (0x03) |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TIMESTAMP |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+
+ Figure 17
+
+ where:
SIZE A 32-bit value containing the length of the signed data in
- bytes (36 bytes) in network byte order.
+ bytes (48 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.
+ PUBLIC KEY / TIMESTAMP Both values as defined in the revocation data
+ object above.
7.1. Verification
@@ -1260,6 +1283,13 @@ Internet-Draft The GNU Name System
November 2019
3. The set of POW values MUST NOT contain duplicates.
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 23]
+
+Internet-Draft The GNU Name System November 2019
+
+
4. The average number of leading zeroes resulting from the provided
POW values D' MUST be greater than D.
@@ -1282,14 +1312,6 @@ Internet-Draft The GNU Name System
November 2019
This is an important distinguishing factor from the Domain Name
System where root zone governance is centralized at the Internet
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 23]
-
-Internet-Draft The GNU Name System November 2019
-
-
Corporation for Assigned Names and Numbers (ICANN). In DNS
terminology, GNS roughly follows the idea of a hyper-hyper local root
zone deployment, with the difference that it is not expected that all
@@ -1315,6 +1337,15 @@ 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 24]
+
+Internet-Draft The GNU Name System November 2019
+
+
Example name: www.example.gnu
Local zones:
fr = (d0,zk0)
@@ -1334,18 +1365,6 @@ Internet-Draft The GNU Name System
November 2019
a locally managed zone and a configuration entry exist for the same
suffix, the locally managed zone MUST have priority.
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 24]
-
-Internet-Draft The GNU Name System November 2019
-
-
Example name: www.example.gnu
Local suffix mappings:
gnu = zk0
@@ -1375,6 +1394,14 @@ Internet-Draft The GNU Name System
November 2019
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
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 25]
+
+Internet-Draft The GNU Name System November 2019
+
+
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
@@ -1393,15 +1420,6 @@ Internet-Draft The GNU Name System
November 2019
* Contact: The contact information of a person to contact for
further information
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 25]
-
-Internet-Draft The GNU Name System November 2019
-
-
* References: Optionally, references describing the record type
(such as an RFC)
@@ -1419,7 +1437,7 @@ Internet-Draft The GNU Name System
November 2019
65541 | BOX | N/A | [This.I-D]
FIXME We have a lot more?
- Figure 17
+ Figure 18
11. Test Vectors
@@ -1432,6 +1450,14 @@ Internet-Draft The GNU Name System
November 2019
71199f7b287cc77a
0d21b5e40a77cb1d
f89333903b284fe8
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 26]
+
+Internet-Draft The GNU Name System November 2019
+
+
1878bf47f3b39da0
zk (public zone key) :=
@@ -1450,14 +1476,6 @@ Internet-Draft The GNU Name System
November 2019
6668e9f684f4dc33
6d656b27392b0fee
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 26]
-
-Internet-Draft The GNU Name System November 2019
-
-
d_h :=
01fb61f482c17633
77611c4c2509e0f3
@@ -1488,6 +1506,14 @@ Internet-Draft The GNU Name System
November 2019
c9d0089df01d0bf4
e4c8db4b2ccc7328
3425e8a811ae59d2
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 27]
+
+Internet-Draft The GNU Name System November 2019
+
+
99e2747285d2a479
TWOFISH_IV :=
@@ -1506,14 +1532,6 @@ Internet-Draft The GNU Name System
November 2019
00000000
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 27]
-
-Internet-Draft The GNU Name System November 2019
-
-
RRBLOCK :=
055cb070e05fe6de SIGNATURE
ad694a50e5b4dedd
@@ -1545,6 +1563,13 @@ Internet-Draft The GNU Name System
November 2019
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 28]
+
+Internet-Draft The GNU Name System November 2019
+
+
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
@@ -1563,13 +1588,6 @@ Internet-Draft The GNU Name System
November 2019
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 28]
-
-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,
@@ -1600,6 +1618,14 @@ Internet-Draft The GNU Name System
November 2019
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <https://www.rfc-editor.org/info/rfc6979>.
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 29]
+
+Internet-Draft The GNU Name System November 2019
+
+
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
@@ -1617,15 +1643,6 @@ Internet-Draft The GNU Name System
November 2019
[TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A
128-Bit Block Cipher, 1st Edition", March 1999.
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 29]
-
-Internet-Draft The GNU Name System November 2019
-
-
[Argon2] Biryukov, A., Dinu, D., Khovratovich, D., and S.
Josefsson, "The memory-hard Argon2 password hash and
proof-of-work function", March 2020,
@@ -1652,6 +1669,19 @@ Authors' Addresses
Email: address@hidden
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 30]
+
+Internet-Draft The GNU Name System November 2019
+
+
Bernd Fix
GNUnet e.V.
Boltzmannstrasse 3
@@ -1677,4 +1707,30 @@ Authors' Addresses
-Schanzenbach, et al. Expires 13 May 2020 [Page 30]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 31]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index dc8a81d..58a4c64 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1133,14 +1133,16 @@
published.
This object MUST be signed using the private zone key.
The revocation object is flooded in the overlay network. To prevent
- flooding attacks, the revocation message MUST contain a proof-of-work.
- The revocation message including the proof-of-work MAY be calculated
+ flooding attacks, the revocation message MUST contain a proof of work
+ (PoW).
+ The revocation message including the PoW MAY be calculated
ahead of time to support timely revocation.
</t>
<t>
For all occurences below, "Argon2d" is the Password-based Key
- Derivation Function as defined in <xref target="Argon2" /> with the
- following fixed parameters:
+ Derivation Function as defined in <xref target="Argon2" />. For the
+ PoW calculations the algorithm is instantiated with the
+ following parameters:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
S := "gnunet-revocation-proof-of-work" /* Salt */
@@ -1153,7 +1155,7 @@
X, K is unused
]]></artwork>
<t>
- The following is the message string "P" on which the proof-of work is
+ The following is the message string "P" on which the PoW is
calculated:
</t>
<figure anchor="figure_revocation">
@@ -1175,7 +1177,7 @@
<dl>
<dt>POW</dt>
<dd>
- A 64-bit solution to the proof of work.
+ A 64-bit solution to the PoW.
</dd>
<dt>TIMESTAMP</dt>
<dd>
@@ -1187,17 +1189,17 @@
<dd>
A 512-bit ECDSA deterministic signature compliant with
<xref target="RFC6979" /> over the public zone zk of the zone
- which is revoked and corresponds to the key used in the
proof-of-work.
+ which is revoked and corresponds to the key used in the PoW.
The signature is created using the private zone key "d" (see
<xref target="zones" />).
</dd>
</dl>
<t>
- Traditionally, proof-of-work schemes require to find a "POW" such that
+ Traditionally, PoW 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.
+ D is then referred to as the "difficulty" of the PoW.
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
+ PoW, we require that a number "Z" different PoWs must be
found that on average have "D" leading zeroes.
</t>
<t>
@@ -1210,13 +1212,16 @@
proof can be increased on demand by the zone owner.
</t>
<t>
- The paraneters are defined as follows:
+ The parameters are defined as follows:
</t>
- <ol>
- <li>Z: The number of PoWs required is fixed at 32.</li>
- <li>D: The difficulty is fixed at 25.</li>
- <li>EPOCH: A single epoch is fixed at 365 days.</li>
- </ol>
+ <dl>
+ <dt>Z</dt>
+ <dd>The number of PoWs required is fixed at 32.</dd>
+ <dt>D</dt>
+ <dd>The difficulty is fixed at 25.</dd>
+ <dt>EPOCH</dt>
+ <dd>A single epoch is fixed at 365 days.</dd>
+ </dl>
<t>
Given that proof has been found, a revocation data object is defined
as follows:
@@ -1244,8 +1249,6 @@
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- | SIZE (0x24) | PURPOSE (0x03) |
- +-----+-----+-----+-----+-----+-----+-----+-----+
| PUBLIC KEY |
| |
| |
@@ -1265,41 +1268,66 @@
<dd>
denotes the relative 64-bit time to live of of the record in
microseconds also in network byte order. This field is informational
- for a verifier. The verifier may discard revocation of the TTL
+ for a verifier. The verifier may discard revocation if the TTL
indicates that it is already expired. However, the actual TTL of the
revocation must be determined by examining the leading zeros in the
proof of work calculation.
</dd>
<dt>POW_i</dt>
<dd>
- The POWs calculated as part of the proof-of-work. Each POW_i MUST
+ The values calculated as part of the PoW. Each POW_i MUST
be unique in the set of POW values.
</dd>
<dt>SIGNATURE</dt>
<dd>
A 512-bit ECDSA deterministic signature compliant with
<xref target="RFC6979" /> over the public zone zk of the zone
- which is revoked and corresponds to the key used in the
proof-of-work.
+ which is revoked and corresponds to the key used in the PoW.
The signature is created using the private zone key "d" (see
<xref target="zones" />).
</dd>
+ <dt>PUBLIC KEY</dt>
+ <dd>
+ 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 <xref target="RFC8032" />,
+ Section 5.1.5.
+ </dd>
+ </dl>
+ <t>
+ The signature over the public key covers a 32 bit pseudo header
+ conceptually prefixed to the public key. The pseudo header includes
+ the key length and signature purpose:
+ </t>
+ <figure anchor="figure_revsigwithpseudo">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | SIZE (0x30) | PURPOSE (0x03) |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TIMESTAMP |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ </figure>
+ <t>where:</t>
+ <dl>
<dt>SIZE</dt>
<dd>
A 32-bit value containing the length of the signed data in bytes
- (36 bytes) in network byte order.
+ (48 bytes) in network byte order.
</dd>
<dt>PURPOSE</dt>
<dd>
A 32-bit signature purpose flag. This field MUST be 3 (in network
byte order).
</dd>
- <dt>PUBLIC KEY</dt>
- <dd>
- 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 <xref target="RFC8032" />,
- Section 5.1.5.
- </dd>
+ <dt>PUBLIC KEY / TIMESTAMP</dt>
+ <dd>Both values as defined in the revocation data object above.</dd>
</dl>
<section anchor="revocation_verification" numbered="true" toc="default">
<name>Verification</name>
--
To stop receiving notification emails like this one, please contact
address@hidden.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: corrections,
gnunet <=