commit c38d4e3f0498bd15cc0d01d5f87869fdbcb7a072
parent da0d4170cdd23d1ef2605f41964a7eb0955d6d98
Author: Schanzenbach, Martin <mschanzenbach@posteo.de>
Date: Sun, 10 May 2020 21:31:20 +0200
remove unnecessary section
Diffstat:
3 files changed, 110 insertions(+), 125 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
@@ -1224,11 +1224,6 @@ 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>
@@ -2612,36 +2607,29 @@ table {
<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>
</dl>
-<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>
+<p id="section-7-21">
+ In order to verify a revocation the following steps must be taken,
+ in order:<a href="#section-7-21" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="normal" id="section-7-22">
+ <li id="section-7-22.1">The current time MUST be between TIMESTAMP and
+ TIMESTAMP+TTL.<a href="#section-7-22.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 id="section-7-22.2">The signature MUST match the public key.<a href="#section-7-22.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 id="section-7-22.3">The set of POW values MUST NOT contain duplicates.<a href="#section-7-22.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 D.<a href="#section-7.1-2.4" class="pilcrow">¶</a>
+<li id="section-7-22.4">The average number of leading zeroes resulting from the provided
+ POW values D' MUST be greater than D.<a href="#section-7-22.4" class="pilcrow">¶</a>
</li>
-<li id="section-7.1-2.5">The validation period (TTL) of the revocation is calculated as
- (D'-D) * EPOCH * 1.1. The EPOCH is extended by
- 10% in order to deal with unsynchronized clocks.
- The TTL added on top of the TIMESTAMP yields the
- expiration date.<a href="#section-7.1-2.5" class="pilcrow">¶</a>
+<li id="section-7-22.5">The validation period (TTL) of the revocation is calculated as
+ (D'-D) * EPOCH * 1.1. The EPOCH is extended by
+ 10% in order to deal with unsynchronized clocks.
+ The TTL added on top of the TIMESTAMP yields the
+ expiration date.<a href="#section-7-22.5" class="pilcrow">¶</a>
</li>
</ol>
</section>
</div>
-</section>
-</div>
<div id="governance">
<section id="section-8">
<h2 id="name-determining-the-root-zone-a">
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
@@ -60,12 +60,12 @@ Internet-Draft The GNU Name System November 2019
Table of Contents
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Resource Records . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Record Types . . . . . . . . . . . . . . . . . . . . . . 6
3.2. PKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.3. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.3. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. LEHO . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. NICK . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
@@ -85,7 +85,6 @@ 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 . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9.1. Abuse mitigation . . . . . . . . . . . . . . . . . . . . 25
@@ -98,14 +97,15 @@ Table of Contents
12. Normative References . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
-1. Introduction
- The Domain Name System (DNS) is a unique distributed database and a
- vital service for most Internet applications. While DNS is
- distributed, it relies on centralized, trusted registrars to provide
- globally unique names. As the awareness of the central role DNS
- plays on the Internet rises, various institutions are using their
- power (including legal means) to engage in attacks on the DNS, thus
+
+
+
+
+
+
+
+
@@ -114,6 +114,14 @@ Schanzenbach, et al. Expires 13 May 2020 [Page 2]
Internet-Draft The GNU Name System November 2019
+1. Introduction
+
+ The Domain Name System (DNS) is a unique distributed database and a
+ vital service for most Internet applications. While DNS is
+ distributed, it relies on centralized, trusted registrars to provide
+ globally unique names. As the awareness of the central role DNS
+ plays on the Internet rises, various institutions are using their
+ power (including legal means) to engage in attacks on the DNS, thus
threatening the global availability and integrity of information on
the Internet.
@@ -151,6 +159,17 @@ Internet-Draft The GNU Name System November 2019
document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 3]
+
+Internet-Draft The GNU Name System November 2019
+
+
2. Zones
A zone in GNS is defined by a public/private ECDSA key pair (d,zk),
@@ -163,13 +182,6 @@ Internet-Draft The GNU Name System November 2019
d is a 256-bit ECDSA private key. In GNS, records are signed using
a key derived from "d" as described in Section 4.
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 3]
-
-Internet-Draft The GNU Name System November 2019
-
-
p is the prime of edwards25519 as defined in [RFC7748], i.e. 2^255
- 19.
@@ -206,6 +218,14 @@ Internet-Draft The GNU Name System November 2019
/ /
/ /
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 4]
+
+Internet-Draft The GNU Name System November 2019
+
+
Figure 1
where:
@@ -217,15 +237,6 @@ 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.
-
-
-
-
-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
@@ -262,6 +273,15 @@ Internet-Draft The GNU Name System November 2019
EXPREL The expiration time value of the record is a relative time
(still in microseconds) and not an absolute time. This flag
should never be encountered by a resolver for records obtained
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 5]
+
+Internet-Draft The GNU Name System November 2019
+
+
from the DHT, but might be present when a resolver looks up
private records of a zone hosted locally.
@@ -274,14 +294,6 @@ 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
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 5]
-
-Internet-Draft The GNU Name System November 2019
-
-
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.
@@ -316,18 +328,6 @@ Internet-Draft The GNU Name System November 2019
PUBLIC KEY A 256-bit ECDSA zone key.
-3.3. GNS2DNS
-
- It is possible to delegate a label back into DNS through a GNS2DNS
- record. The resource record contains a DNS name for the resolver to
- continue with in DNS followed by a DNS server. Both names are in the
- format defined in [RFC1034] for DNS names. A GNS2DNS DATA entry has
- the following format:
-
-
-
-
-
@@ -338,6 +338,14 @@ Schanzenbach, et al. Expires 13 May 2020 [Page 6]
Internet-Draft The GNU Name System November 2019
+3.3. GNS2DNS
+
+ It is possible to delegate a label back into DNS through a GNS2DNS
+ record. The resource record contains a DNS name for the resolver to
+ continue with in DNS followed by a DNS server. Both names are in the
+ format defined in [RFC1034] for DNS names. A GNS2DNS DATA entry has
+ the following format:
+
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| DNS NAME |
@@ -379,14 +387,6 @@ Internet-Draft The GNU Name System November 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 5
-
- where:
-
- LEGACY HOSTNAME A UTF-8 string (which is not 0-terminated)
- representing the legacy hostname.
-
-
Schanzenbach, et al. Expires 13 May 2020 [Page 7]
@@ -394,6 +394,13 @@ Schanzenbach, et al. Expires 13 May 2020 [Page 7]
Internet-Draft The GNU Name System November 2019
+ Figure 5
+
+ where:
+
+ LEGACY HOSTNAME A UTF-8 string (which is not 0-terminated)
+ representing the legacy hostname.
+
NOTE: If an application uses a LEHO value in an HTTP request header
(e.g. "Host:" header) it must be converted to a punycode
representation [RFC5891].
@@ -435,13 +442,6 @@ Internet-Draft The GNU Name System November 2019
format to box up SRV and TLSA records and include them in the record
set of the label they are associated with. For example, a TLSA
record for "_https._tcp.foo.gnu" will be stored in the record set of
- "foo.gnu" as a BOX record with service (SVC) 443 (https) and protocol
- (PROTO) 6 (tcp) and record TYPE "TLSA". For reference, see also
- [RFC2782]. A BOX DATA entry has the following format:
-
-
-
-
@@ -450,6 +450,10 @@ Schanzenbach, et al. Expires 13 May 2020 [Page 8]
Internet-Draft The GNU Name System November 2019
+ "foo.gnu" as a BOX record with service (SVC) 443 (https) and protocol
+ (PROTO) 6 (tcp) and record TYPE "TLSA". For reference, see also
+ [RFC2782]. A BOX DATA entry has the following format:
+
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| PROTO | SVC | TYPE |
@@ -494,10 +498,6 @@ Internet-Draft The GNU Name System November 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 8
-
- where:
-
@@ -506,6 +506,10 @@ Schanzenbach, et al. Expires 13 May 2020 [Page 9]
Internet-Draft The GNU Name System November 2019
+ Figure 8
+
+ where:
+
HOSTING PEER PUBLIC KEY is a 256-bit EdDSA public key identifying
the peer hosting the service.
@@ -550,10 +554,6 @@ Internet-Draft The GNU Name System November 2019
d is the 256-bit private zone key as defined in Section 2.
- label is a UTF-8 string under which the resource records are
- published.
-
-
@@ -562,6 +562,9 @@ Schanzenbach, et al. Expires 13 May 2020 [Page 10]
Internet-Draft The GNU Name System November 2019
+ label is a UTF-8 string under which the resource records are
+ published.
+
d_h is a 256-bit private key derived from the "d" using the keying
material "h".
@@ -610,9 +613,6 @@ Internet-Draft The GNU Name System November 2019
-
-
-
Schanzenbach, et al. Expires 13 May 2020 [Page 11]
Internet-Draft The GNU Name System November 2019
@@ -1270,8 +1270,6 @@ Internet-Draft The GNU Name System November 2019
PUBLIC KEY / TIMESTAMP Both values as defined in the revocation data
object above.
-7.1. Verification
-
In order to verify a revocation the following steps must be taken, in
order:
@@ -1281,6 +1279,8 @@ Internet-Draft The GNU Name System November 2019
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 D.
@@ -1290,9 +1290,6 @@ 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.
-
5. The validation period (TTL) of the revocation is calculated as
(D'-D) * EPOCH * 1.1. The EPOCH is extended by 10% in order to
deal with unsynchronized clocks. The TTL added on top of the
@@ -1341,6 +1338,9 @@ Internet-Draft The GNU Name System November 2019
+
+
+
Schanzenbach, et al. Expires 13 May 2020 [Page 24]
Internet-Draft The GNU Name System November 2019
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -1329,26 +1329,23 @@
<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>
- <t>
- In order to verify a revocation the following steps must be taken,
- in order:
- </t>
- <ol>
- <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 D.</li>
- <li>The validation period (TTL) of the revocation is calculated as
- (D'-D) * EPOCH * 1.1. The EPOCH is extended by
- 10% in order to deal with unsynchronized clocks.
- The TTL added on top of the TIMESTAMP yields the
- expiration date.</li>
- </ol>
- </section>
+ <t>
+ In order to verify a revocation the following steps must be taken,
+ in order:
+ </t>
+ <ol>
+ <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 D.</li>
+ <li>The validation period (TTL) of the revocation is calculated as
+ (D'-D) * EPOCH * 1.1. The EPOCH is extended by
+ 10% in order to deal with unsynchronized clocks.
+ The TTL added on top of the TIMESTAMP yields the
+ expiration date.</li>
+ </ol>
</section>
<section anchor="governance" numbered="true" toc="default">
<name>Determining the Root Zone and Zone Governance</name>
