aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMartin Schanzenbach <mschanzenbach@posteo.de>2020-07-06 17:49:26 +0200
committerMartin Schanzenbach <mschanzenbach@posteo.de>2020-07-06 17:49:26 +0200
commitb5842447f6748b2e1a9525d8982777f9aafcc6eb (patch)
treed4254f813530511cdd032e27fd7c302672577964
parenta9417625cfdb2478ccb9d79d188578ee811a5ae8 (diff)
downloadlsd0001-b5842447f6748b2e1a9525d8982777f9aafcc6eb.tar.gz
lsd0001-b5842447f6748b2e1a9525d8982777f9aafcc6eb.zip
add the 01 submission
Diffstat
-rw-r--r--draft-schanzen-gns-01.xml1918
-rw-r--r--draft-schanzen-gns.xml4
2 files changed, 1920 insertions, 2 deletions
diff --git a/draft-schanzen-gns-01.xml b/draft-schanzen-gns-01.xml
new file mode 100644
index 0000000..b7597ac
--- /dev/null
+++ b/draft-schanzen-gns-01.xml
@@ -0,0 +1,1918 @@
1<?xml version='1.0' encoding='utf-8'?>
2<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
3<!ENTITY RFC1034 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml">
4<!ENTITY RFC1035 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
5<!ENTITY RFC2119 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
6<!ENTITY RFC2782 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
7<!ENTITY RFC3629 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
8<!ENTITY RFC3826 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml">
9<!ENTITY RFC3912 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3912.xml">
10<!ENTITY RFC5869 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml">
11<!ENTITY RFC5890 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
12<!ENTITY RFC5891 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5891.xml">
13<!ENTITY RFC6781 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6781.xml">
14<!ENTITY RFC6895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml">
15<!ENTITY RFC6979 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml">
16<!ENTITY RFC7748 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7748.xml">
17<!ENTITY RFC8032 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml">
18<!ENTITY RFC8126 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
19]>
20<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
21<?rfc strict="yes" ?>
22<?rfc toc="yes" ?>
23<?rfc symrefs="yes"?>
24<?rfc sortrefs="yes" ?>
25<?rfc compact="yes" ?>
26<?rfc subcompact="no" ?>
27<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-schanzen-gns-01" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
28 <!-- xml2rfc v2v3 conversion 2.26.0 -->
29 <front>
30 <title abbrev="The GNU Name System">
31 The GNU Name System
32 </title>
33 <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-01"/>
34 <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach">
35 <organization>GNUnet e.V.</organization>
36 <address>
37 <postal>
38 <street>Boltzmannstrasse 3</street>
39 <city>Garching</city>
40 <code>85748</code>
41 <country>DE</country>
42 </postal>
43 <email>schanzen@gnunet.org</email>
44 </address>
45 </author>
46 <author fullname="Christian Grothoff" initials="C." surname="Grothoff">
47 <organization>Berner Fachhochschule</organization>
48 <address>
49 <postal>
50 <street>Hoeheweg 80</street>
51 <city>Biel/Bienne</city>
52 <code>2501</code>
53 <country>CH</country>
54 </postal>
55 <email>grothoff@gnunet.org</email>
56 </address>
57 </author>
58 <author fullname="Bernd Fix" initials="B." surname="Fix">
59 <organization>GNUnet e.V.</organization>
60 <address>
61 <postal>
62 <street>Boltzmannstrasse 3</street>
63 <city>Garching</city>
64 <code>85748</code>
65 <country>DE</country>
66 </postal>
67 <email>fix@gnunet.org</email>
68 </address>
69 </author>
70
71 <!-- Meta-data Declarations -->
72 <area>General</area>
73 <workgroup>Independent Stream</workgroup>
74 <keyword>name systems</keyword>
75 <abstract>
76 <t>This document contains the GNU Name System (GNS) technical specification.</t>
77 </abstract>
78 </front>
79 <middle>
80 <section anchor="introduction" numbered="true" toc="default">
81 <name>Introduction</name>
82 <t>
83 The Domain Name System (DNS) is a unique distributed database and a vital
84 service for most Internet applications. While DNS is distributed, it
85 relies on centralized, trusted registrars to provide globally unique
86 names. As the awareness of the central role DNS plays on the Internet
87 rises, various institutions are using their power (including legal means)
88 to engage in attacks on the DNS, thus threatening the global availability
89 and integrity of information on the Internet.
90 </t>
91 <t>
92 DNS was not designed with security as a goal. This makes it very
93 vulnerable, especially to attackers that have the technical capabilities
94 of an entire nation state at their disposal.
95 This specification describes a censorship-resistant, privacy-preserving
96 and decentralized name system: The GNU Name System (GNS). It is designed
97 to provide a secure alternative to DNS, especially when censorship or
98 manipulation is encountered. GNS can bind names to any kind of
99 cryptographically secured token, enabling it to double in some respects as
100 even as an alternative to some of today’s Public Key Infrastructures, in
101 particular X.509 for the Web.
102 </t>
103 <t>
104 This document contains the GNU Name System (GNS) technical specification
105 of the GNU Name System <xref target="GNS" />, a fully decentralized and censorship-resistant
106 name system. GNS provides a privacy-enhancing alternative to the Domain
107 Name System (DNS). The design of GNS incorporates the capability to
108 integrate and coexist with DNS. GNS is based on the principle of a petname
109 system and builds on ideas from the Simple Distributed Security
110 Infrastructure (SDSI), addressing a central issue with the decentralized
111 mapping of secure identifiers to memorable names: namely the impossibility
112 of providing a global, secure and memorable mapping without a trusted
113 authority. GNS uses the transitivity in the SDSI design to replace the
114 trusted root with secure delegation of authority thus making petnames
115 useful to other users while operating under a very strong adversary model.
116 </t>
117 <t>
118 This document defines the normative wire format of resource records, resolution processes,
119 cryptographic routines and security considerations for use by implementors.
120 </t>
121 <t>
122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
123 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
124 "OPTIONAL" in this document are to be interpreted as described
125 in <xref target="RFC2119"/>.
126 </t>
127 <t>
128
129 </t>
130 </section>
131 <section anchor="zones" numbered="true" toc="default">
132 <name>Zones</name>
133 <t>
134 A zone in GNS is defined by a public/private ECDSA key pair (d,zk),
135 where d is the private key and zk the corresponding public key.
136 GNS employs the curve parameters of the twisted edwards representation
137 of Curve25519 <xref target="RFC7748" /> (a.k.a. edwards25519)
138 with the ECDSA scheme (<xref target="RFC6979" />).
139 In the following, we use the following naming convention for our
140 cryptographic primitives:
141 </t>
142 <dl>
143 <dt>d</dt>
144 <dd>
145 is a 256-bit ECDSA private key.
146 In GNS, records are signed using a key derived from "d" as described in
147 <xref target="publish" />.
148 </dd>
149 <dt>p</dt>
150 <dd>
151 is the prime of edwards25519 as defined in <xref target="RFC7748" />, i.e.
152 2^255 - 19.
153 </dd>
154 <dt>B</dt>
155 <dd>
156 is the group generator (X(P),Y(P)) of edwards25519 as defined in
157 <xref target="RFC7748" />.
158 </dd>
159 <dt>L</dt>
160 <dd>
161 is the prime-order subgroup of edwards25519 in <xref target="RFC7748" />.
162 </dd>
163 <dt>zk</dt>
164 <dd>
165 is the ECDSA public key corresponding to d. It is defined in
166 <xref target="RFC6979" /> as the curve point d*B where B is the group
167 generator of the elliptic curve. The public key is used to uniquely
168 identify a GNS zone and is referred to as the "zone key".
169 </dd>
170 </dl>
171 </section>
172 <section anchor="rrecords" numbered="true" toc="default">
173 <name>Resource Records</name>
174 <t>
175 A GNS implementor MUST provide a mechanism to create and manage resource
176 records for local zones. A local zone is established by creating a zone
177 key pair. Records may be added to each zone, hence a (local) persistency
178 mechanism for resource records and zones must be provided.
179 This local zone database is used by the GNS resolver implementation
180 and to publish record information.
181 </t>
182 <t>
183 A GNS resource record holds the data of a specific record in a zone.
184 The resource record format is defined as follows:
185 </t>
186 <figure anchor="figure_gnsrecord">
187 <artwork name="" type="" align="left" alt=""><![CDATA[
1880 8 16 24 32 40 48 56
189+-----+-----+-----+-----+-----+-----+-----+-----+
190| EXPIRATION |
191+-----+-----+-----+-----+-----+-----+-----+-----+
192| DATA SIZE | TYPE |
193+-----+-----+-----+-----+-----+-----+-----+-----+
194| FLAGS | DATA /
195+-----+-----+-----+-----+ /
196/ /
197/ /
198 ]]></artwork>
199 <!-- <postamble>which is a very simple example.</postamble>-->
200 </figure>
201 <t>where:</t>
202 <dl>
203 <dt>EXPIRATION</dt>
204 <dd>
205 denotes the absolute 64-bit expiration date of the record.
206 In microseconds since midnight (0 hour), January 1, 1970 in network
207 byte order.
208 </dd>
209 <dt>DATA SIZE</dt>
210 <dd>
211 denotes the 32-bit size of the DATA field in bytes and in network byte
212 order.
213 </dd>
214 <dt>TYPE</dt>
215 <dd>
216 is the 32-bit resource record type. This type can be one of the GNS resource
217 records as defined in <xref target="rrecords" /> or a DNS record
218 type as defined in <xref target="RFC1035" /> or any of the
219 complementary standardized DNS resource record types. This value must be
220 stored in network byte order. Note that values
221 below 2^16 are reserved for allocation via IANA (<xref target="RFC6895" />).
222 </dd>
223 <dt>FLAGS</dt>
224 <dd>
225 is a 32-bit resource record flags field (see below).
226 </dd>
227 <dt>DATA</dt>
228 <dd>
229 the variable-length resource record data payload. The contents are defined
230 by the
231 respective type of the resource record.
232 </dd>
233 </dl>
234 <t>
235 Flags indicate metadata surrounding the resource record. A flag
236 value of 0 indicates that all flags are unset. The following
237 illustrates the flag distribution in the 32-bit flag value of a
238 resource record:</t>
239 <figure anchor="figure_flag">
240 <artwork name="" type="" align="left" alt=""><![CDATA[
241... 5 4 3 2 1 0
242------+--------+--------+--------+--------+--------+
243/ ... | SHADOW | EXPREL | SUPPL | PRIVATE| / |
244------+--------+--------+--------+--------+--------+
245 ]]></artwork>
246 <!-- <postamble>which is a very simple example.</postamble>-->
247 </figure>
248 <t>
249 where:
250 </t>
251 <dl>
252 <dt>SHADOW</dt>
253 <dd>
254 If this flag is set, this record should be ignored by resolvers unless all (other)
255 records of the same record type have expired. Used to allow zone publishers to
256 facilitate good performance when records change by allowing them to put future
257 values of records into the DHT. This way, future values can propagate and may be
258 cached before the transition becomes active.
259 </dd>
260 <dt>EXPREL</dt>
261 <dd>
262 The expiration time value of the record is a relative time (still in microseconds)
263 and not an absolute time. This flag should never be encountered by a resolver
264 for records obtained from the DHT, but might be present when a resolver looks up
265 private records of a zone hosted locally.
266 </dd>
267 <dt>
268 SUPPL
269 </dt>
270 <dd>
271 This is a supplemental record. It is provided in addition to the
272 other records. This flag indicates that this record is not explicitly
273 managed alongside the other records under the respective name but
274 may be useful for the application. This flag should only be encountered
275 by a resolver for records obtained from the DHT.
276 </dd>
277 <dt>PRIVATE</dt>
278 <dd>
279 This is a private record of this peer and it should thus not be
280 published in the DHT. Thus, this flag should never be encountered by
281 a resolver for records obtained from the DHT.
282 Private records should still be considered just like
283 regular records when resolving labels in local zones.
284 </dd>
285 </dl>
286 <section anchor="gnsrecords_numbers" numbered="true" toc="default">
287 <name>Record Types</name>
288 <t>
289 A registry of GNS Record Types is described in Section 10. The
290 registration policy for this registry is "First Come First Served", as
291 described in <xref target="RFC8126"/>. When requesting new entries, careful
292 consideration of the following criteria is strongly advised:
293 FIXME: ausdenken was wir da gerne haetten.
294 </t>
295 </section>
296 <section anchor="gnsrecords_pkey" numbered="true" toc="default">
297 <name>PKEY</name>
298 <t>In GNS, a delegation of a label to a zone is represented through a PKEY
299 record. A PKEY resource record contains the public key of the zone to
300 delegate to. A PKEY record MUST be the only record under a label. No other
301 records are allowed. A PKEY DATA entry has the following format:</t>
302 <figure anchor="figure_pkeyrecord">
303 <artwork name="" type="" align="left" alt=""><![CDATA[
3040 8 16 24 32 40 48 56
305+-----+-----+-----+-----+-----+-----+-----+-----+
306| PUBLIC KEY |
307| |
308| |
309| |
310+-----+-----+-----+-----+-----+-----+-----+-----+
311 ]]></artwork>
312 <!-- <postamble>which is a very simple example.</postamble>-->
313 </figure>
314 <t>
315 where:
316 </t>
317 <dl>
318 <dt>PUBLIC KEY</dt>
319 <dd>
320 A 256-bit ECDSA zone key.
321 </dd>
322 </dl>
323 </section>
324 <section anchor="gnsrecords_gns2dns" numbered="true" toc="default">
325 <name>GNS2DNS</name>
326 <t>It is possible to delegate a label back into DNS through a GNS2DNS record.
327 The resource record contains a DNS name for the resolver to continue with
328 in DNS followed by a DNS server. Both names are in the format defined in
329 <xref target="RFC1034" /> for DNS names.
330 A GNS2DNS DATA entry has the following format:</t>
331 <figure anchor="figure_gns2dnsrecord">
332 <artwork name="" type="" align="left" alt=""><![CDATA[
3330 8 16 24 32 40 48 56
334+-----+-----+-----+-----+-----+-----+-----+-----+
335| DNS NAME |
336/ /
337/ /
338| |
339+-----+-----+-----+-----+-----+-----+-----+-----+
340| DNS SERVER NAME |
341/ /
342/ /
343| |
344+-----------------------------------------------+
345 ]]></artwork>
346 <!-- <postamble>which is a very simple example.</postamble>-->
347 </figure>
348 <t>
349 where:
350 </t>
351 <dl>
352 <dt>DNS NAME</dt>
353 <dd>
354 The name to continue with in DNS (0-terminated).
355 </dd>
356 <dt>DNS SERVER NAME</dt>
357 <dd>
358 The DNS server to use. May be an IPv4/IPv6 address in dotted decimal
359 form or a DNS name. It may also be a relative GNS name ending with a
360 "+" top-level domain. The value is UTF-8 encoded (also for DNS names)
361 and 0-terminated.
362 </dd>
363 </dl>
364 </section>
365
366 <section anchor="gnsrecords_leho" numbered="true" toc="default">
367 <name>LEHO</name>
368 <t>Legacy hostname records can be used by applications that are expected
369 to supply a DNS name on the application layer. The most common use case
370 is HTTP virtual hosting, which as-is would not work with GNS names as
371 those may not be globally unique.
372
373 A LEHO resource record is expected to be found together in a single
374 resource record with an IPv4 or IPv6 address.
375 A LEHO DATA entry has the following format:</t>
376 <figure anchor="figure_lehorecord">
377 <artwork name="" type="" align="left" alt=""><![CDATA[
3780 8 16 24 32 40 48 56
379+-----+-----+-----+-----+-----+-----+-----+-----+
380| LEGACY HOSTNAME |
381/ /
382/ /
383| |
384+-----+-----+-----+-----+-----+-----+-----+-----+
385 ]]></artwork>
386 <!-- <postamble>which is a very simple example.</postamble>-->
387 </figure>
388 <t>
389 where:
390 </t>
391 <dl>
392 <dt>LEGACY HOSTNAME</dt>
393 <dd>
394 A UTF-8 string (which is not 0-terminated) representing the legacy hostname.
395 </dd>
396 </dl>
397 <t>
398 NOTE: If an application uses a LEHO value in an HTTP request header
399 (e.g. "Host:" header) it must be converted to a punycode representation
400 <xref target="RFC5891" />.
401 </t>
402 </section>
403 <section anchor="gnsrecords_nick" numbered="true" toc="default">
404 <name>NICK</name>
405 <t>
406 Nickname records can be used by zone administrators to publish an
407 indication on what label this zone prefers to be referred to.
408 This is a suggestion to other zones what label to use when creating a
409 PKEY (<xref target="gnsrecords_pkey" />) record containing this zone's
410 public zone key.
411 This record SHOULD only be stored under the empty label "@" but MAY be
412 returned with record sets under any label as a supplemental record.
413 <xref target="nick_processing"/> details how a resolver must process
414 supplemental and non-supplemental NICK records.
415 A NICK DATA entry has the following format:
416 </t>
417 <figure anchor="figure_nickrecord">
418 <artwork name="" type="" align="left" alt=""><![CDATA[
4190 8 16 24 32 40 48 56
420+-----+-----+-----+-----+-----+-----+-----+-----+
421| NICKNAME |
422/ /
423/ /
424| |
425+-----+-----+-----+-----+-----+-----+-----+-----+
426 ]]></artwork>
427 <!-- <postamble>which is a very simple example.</postamble>-->
428 </figure>
429 <t>
430 where:
431 </t>
432 <dl>
433 <dt>NICKNAME</dt>
434 <dd>
435 A UTF-8 string (which is not 0-terminated) representing the preferred
436 label of the zone. This string MUST NOT include a "." character.
437 </dd>
438 </dl>
439 </section>
440 <section anchor="gnsrecords_box" numbered="true" toc="default">
441 <name>BOX</name>
442 <t>
443 In GNS, every "." in a name delegates to another zone, and
444 GNS lookups are expected to return all of the required useful
445 information in one record set. This is incompatible with the
446 special labels used by DNS for SRV and TLSA records. Thus, GNS
447 defines the BOX record format to box up SRV and TLSA records and
448 include them in the record set of the label they are associated
449 with. For example, a
450 TLSA record for "_https._tcp.example.org" will be stored in the record set of
451 "example.org" as a BOX record with service (SVC) 443 (https) and protocol (PROTO) 6
452 (tcp) and record TYPE "TLSA".
453 For reference, see also <xref target="RFC2782" />.
454 A BOX DATA entry has the following format:
455 </t>
456 <figure anchor="figure_boxrecord">
457 <artwork name="" type="" align="left" alt=""><![CDATA[
4580 8 16 24 32 40 48 56
459+-----+-----+-----+-----+-----+-----+-----+-----+
460| PROTO | SVC | TYPE |
461+-----------+-----------------------------------+
462| RECORD DATA |
463/ /
464/ /
465| |
466+-----+-----+-----+-----+-----+-----+-----+-----+
467 ]]></artwork>
468 <!-- <postamble>which is a very simple example.</postamble>-->
469 </figure>
470 <t>
471 where:
472 </t>
473 <dl>
474 <dt>PROTO</dt>
475 <dd>
476 the 16-bit protocol number, e.g. 6 for tcp. In network byte order.
477 </dd>
478 <dt>SVC</dt>
479 <dd>
480 the 16-bit service value of the boxed record, i.e. the port number.
481 In network byte order.
482 </dd>
483 <dt>TYPE</dt>
484 <dd>
485 is the 32-bit record type of the boxed record. In network byte order.
486 </dd>
487 <dt>RECORD DATA</dt>
488 <dd>
489 is a variable length field containing the "DATA" format of TYPE as
490 defined for the respective TYPE in DNS.
491 </dd>
492 </dl>
493 </section>
494 <section anchor="gnsrecords_vpn" numbered="true" toc="default">
495 <name>VPN</name>
496 <t>
497 A VPN DATA entry has the following format:</t>
498 <figure anchor="figure_vpnrecord">
499 <artwork name="" type="" align="left" alt=""><![CDATA[
5000 8 16 24 32 40 48 56
501+-----+-----+-----+-----+-----+-----+-----+-----+
502| HOSTING PEER PUBLIC KEY |
503| (256 bits) |
504| |
505| |
506+-----------+-----------------------------------+
507| PROTO | SERVICE NAME |
508+-----------+ +
509/ /
510/ /
511| |
512+-----+-----+-----+-----+-----+-----+-----+-----+
513 ]]></artwork>
514 <!-- <postamble>which is a very simple example.</postamble>-->
515 </figure>
516 <t>
517 where:
518 </t>
519 <dl>
520 <dt>HOSTING PEER PUBLIC KEY</dt>
521 <dd>
522 is a 256-bit EdDSA public key identifying the peer hosting the
523 service.
524 </dd>
525 <dt>PROTO</dt>
526 <dd>
527 the 16-bit protocol number, e.g. 6 for TCP. In network byte order.
528 </dd>
529 <dt>SERVICE NAME</dt>
530 <dd>
531 a shared secret used to identify the service at the hosting peer,
532 used to derive the port number requird to connect to the service.
533 The service name MUST be a 0-terminated UTF-8 string.
534 </dd>
535 </dl>
536 </section>
537 </section>
538
539 <section anchor="publish" numbered="true" toc="default">
540 <name>Publishing Records</name>
541 <t>
542 GNS resource records are published in a distributed hash table (DHT).
543 We assume that a DHT provides two functions: GET(key) and PUT(key,value).
544 In GNS, resource records are grouped by their respective labels,
545 encrypted and published together in a single resource records block
546 (RRBLOCK) in the DHT under a key "q": PUT(q, RRBLOCK).
547 The key "q" which is derived from the zone key "zk" and the respective
548 label of the contained records.
549 </t>
550 <section anchor="blinding" numbered="true" toc="default">
551 <name>Key Derivations</name>
552 <t>
553 Given a label, the DHT key "q" is derived as follows:
554 </t>
555 <artwork name="" type="" align="left" alt=""><![CDATA[
556PRK_h := HKDF-Extract ("key-derivation", zk)
557h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
558d_h := h * d mod L
559zk_h := h mod L * zk
560q := SHA512 (zk_h)
561 ]]></artwork>
562 <t>
563 We use a hash-based key derivation function (HKDF) as defined in
564 <xref target="RFC5869" />. We use HMAC-SHA512 for the extraction
565 phase and HMAC-SHA256 for the expansion phase.
566 </t>
567 <dl>
568 <dt>PRK_h</dt>
569 <dd>
570 is key material retrieved using an HKDF using the string
571 "key-derivation" as salt and the public zone key "zk" as initial
572 keying material.
573 </dd>
574 <dt>h</dt>
575 <dd>
576 is the 512-bit HKDF expansion result. The expansion info input is a
577 concatenation of the label and string "gns".
578 </dd>
579 <dt>d</dt>
580 <dd>
581 is the 256-bit private zone key as defined in <xref target="zones" />.
582 </dd>
583 <dt>label</dt>
584 <dd>is a UTF-8 string under which the resource records are published.
585 </dd>
586 <dt>d_h</dt>
587 <dd>
588 is a 256-bit private key derived from the "d" using the
589 keying material "h".
590 </dd>
591 <dt>zk_h</dt>
592 <dd>
593 is a 256-bit public key derived from the zone key "zk" using the
594 keying material "h".
595 </dd>
596 <dt>L</dt>
597 <dd>
598 is the prime-order subgroup as defined in <xref target="zones" />.
599 </dd>
600 <dt>q</dt>
601 <dd>
602 Is the 512-bit DHT key under which the resource records block is
603 published.
604 It is the SHA512 hash over the public key "zk_h" corresponding to the
605 derived private key "d_h".
606 </dd>
607 </dl>
608 <t>
609 We point out that the multiplication of "zk" with "h" is a point multiplication,
610 while the multiplication of "d" with "h" is a scalar multiplication.
611 </t>
612 </section>
613 <section anchor="wire" numbered="true" toc="default">
614 <name>Resource Records Block</name>
615 <t>
616 GNS records are grouped by their labels and published as a single
617 block in the DHT. The grouped record sets MAY be paired with any
618 number of supplemental records. Supplemental records must have the
619 supplemental flag set (See <xref target="rrecords"/>).
620 The contained resource records are encrypted using a symmetric
621 encryption scheme.
622 A GNS implementation must publish RRBLOCKs
623 in accordance to the properties and recommendations of the underlying
624 DHT. This may include a periodic refresh publication.
625 A GNS RRBLOCK has the following format:
626 </t>
627 <figure anchor="figure_record_block">
628 <artwork name="" type="" align="left" alt=""><![CDATA[
6290 8 16 24 32 40 48 56
630+-----+-----+-----+-----+-----+-----+-----+-----+
631| SIGNATURE |
632| |
633| |
634| |
635| |
636| |
637| |
638| |
639+-----+-----+-----+-----+-----+-----+-----+-----+
640| PUBLIC KEY |
641| |
642| |
643| |
644+-----+-----+-----+-----+-----+-----+-----+-----+
645| SIZE | PURPOSE |
646+-----+-----+-----+-----+-----+-----+-----+-----+
647| EXPIRATION |
648+-----+-----+-----+-----+-----+-----+-----+-----+
649| BDATA /
650/ /
651/ |
652+-----+-----+-----+-----+-----+-----+-----+-----+
653 ]]></artwork>
654 </figure>
655 <t>where:</t>
656 <dl>
657 <dt>SIGNATURE</dt>
658 <dd>
659 A 512-bit ECDSA deterministic signature compliant with
660 <xref target="RFC6979" />. The signature is computed over the data
661 following the PUBLIC KEY field.
662 The signature is created using the derived private key "d_h" (see
663 <xref target="publish" />).
664 </dd>
665 <dt>PUBLIC KEY</dt>
666 <dd>
667 is the 256-bit public key "zk_h" to be used to verify SIGNATURE. The
668 wire format of this value is defined in <xref target="RFC8032" />,
669 Section 5.1.5.
670 </dd>
671 <dt>SIZE</dt>
672 <dd>
673 A 32-bit value containing the length of the signed data following the
674 PUBLIC KEY field in network byte order. This value always includes the
675 length of the fields SIZE (4), PURPOSE (4) and EXPIRATION (8) in
676 addition to the length of the BDATA. While a 32-bit value is used,
677 implementations MAY refuse to publish blocks beyond a certain
678 size significantly below 4 GB. However, a minimum block size of
679 62 kilobytes MUST be supported.
680 <!-- See GNUNET_CONSTANTS_MAX_BLOCK_SIZE -->
681 </dd>
682 <dt>PURPOSE</dt>
683 <dd>
684 A 32-bit signature purpose flag. This field MUST be 15 (in network
685 byte order).
686 </dd>
687 <dt>EXPIRATION</dt>
688 <dd>
689 Specifies when the RRBLOCK expires and the encrypted block
690 SHOULD be removed from the DHT and caches as it is likely stale.
691 However, applications MAY continue to use non-expired individual
692 records until they expire. The value MUST be set to the
693 expiration time of the resource record contained within this block with the
694 smallest expiration time.
695 If a records block includes shadow records, then the maximum
696 expiration time of all shadow records with matching type and the
697 expiration times of the non-shadow records is considered.
698 This is a 64-bit absolute date in microseconds since midnight
699 (0 hour), January 1, 1970 in network byte order.
700 </dd>
701 <dt>BDATA</dt>
702 <dd>
703 The encrypted resource records with a total size of SIZE - 16.
704 </dd>
705 </dl>
706 </section>
707 <section anchor="recordencryption" numbered="true" toc="default">
708 <name>Record Data Encryption and Decryption</name>
709 <t>
710 A symmetric encryption scheme is used to encrypt the resource records
711 set RDATA into the BDATA field of a GNS RRBLOCK.
712 The wire format of the RDATA looks as follows:
713 </t>
714 <figure anchor="figure_rdata">
715 <artwork name="" type="" align="left" alt=""><![CDATA[
7160 8 16 24 32 40 48 56
717+-----+-----+-----+-----+-----+-----+-----+-----+
718| RR COUNT | EXPIRA- /
719+-----+-----+-----+-----+-----+-----+-----+-----+
720/ -TION | DATA SIZE |
721+-----+-----+-----+-----+-----+-----+-----+-----+
722| TYPE | FLAGS |
723+-----+-----+-----+-----+-----+-----+-----+-----+
724| DATA /
725/ /
726/ |
727+-----+-----+-----+-----+-----+-----+-----+-----+
728| EXPIRATION |
729+-----+-----+-----+-----+-----+-----+-----+-----+
730| DATA SIZE | TYPE |
731+-----+-----+-----+-----+-----+-----+-----+-----+
732| FLAGS | DATA /
733+-----+-----+-----+-----+ /
734/ +-----------------------/
735/ | /
736+-----------------------+ /
737/ PADDING /
738/ /
739 ]]></artwork>
740 <!-- <postamble>which is a very simple example.</postamble>-->
741 </figure>
742 <t>where:</t>
743 <dl>
744 <dt>RR COUNT</dt>
745 <dd>
746 A 32-bit value containing the number of variable-length resource
747 records which are
748 following after this field in network byte order.
749 </dd>
750 <dt>EXPIRATION, DATA SIZE, TYPE, FLAGS and DATA</dt>
751 <dd>
752 These fields were defined
753 in the resource record format in <xref target="rrecords" />.
754 There MUST be a total of RR COUNT of these resource records
755 present.
756 </dd>
757 <dt>PADDING</dt>
758 <dd>
759 The padding MUST contain the value 0 in all octets.
760 The padding MUST ensure that the size of the RDATA WITHOUT the RR
761 COUNT field is a power of two.
762 As a special exception, record sets with (only) a PKEY record type
763 are never padded. Note that a record set with a PKEY record MUST NOT
764 contain other records.
765 </dd>
766
767 </dl>
768 <t>
769 The symmetric keys and initialization vectors are derived from the
770 record label and the zone key "zk". For decryption of the resource
771 records block payload, the key material "K" and initialization vector
772 "IV" for the symmetric cipher are derived as follows:
773 </t>
774 <!-- OLD VERSION
775 PRK_kiv := HKDF-Extract (zk, label)
776 K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
777 IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
778 -->
779 <artwork name="" type="" align="left" alt=""><![CDATA[
780PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
781PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
782K := HKDF-Expand (PRK_k, label, 512 / 8);
783IV := HKDF-Expand (PRK_iv, label, 256 / 8)
784 ]]></artwork>
785 <t>
786 HKDF is a hash-based key derivation function as defined in
787 <xref target="RFC5869" />. Specifically, HMAC-SHA512 is used for the
788 extraction phase and HMAC-SHA256 for the expansion phase.
789 The output keying material is 64 octets (512 bit) for the symmetric
790 keys and 32 octets (256 bit) for the initialization vectors.
791 We divide the resulting keying material "K" into a 256-bit AES
792 <xref target="RFC3826" /> key
793 and a 256-bit TWOFISH <xref target="TWOFISH" /> key:
794 </t>
795 <figure anchor="figure_hkdf_keys">
796 <artwork name="" type="" align="left" alt=""><![CDATA[
7970 8 16 24 32 40 48 56
798+-----+-----+-----+-----+-----+-----+-----+-----+
799| AES KEY |
800| |
801| |
802| |
803+-----+-----+-----+-----+-----+-----+-----+-----+
804| TWOFISH KEY |
805| |
806| |
807| |
808+-----+-----+-----+-----+-----+-----+-----+-----+
809 ]]></artwork>
810 <!-- <postamble>which is a very simple example.</postamble>-->
811 </figure>
812 <t>
813 Similarly, we divide "IV" into a 128-bit initialization vector
814 and a 128-bit initialization vector:
815 </t>
816 <figure anchor="figure_hkdf_ivs">
817 <artwork name="" type="" align="left" alt=""><![CDATA[
8180 8 16 24 32 40 48 56
819+-----+-----+-----+-----+-----+-----+-----+-----+
820| AES IV |
821| |
822+-----+-----+-----+-----+-----+-----+-----+-----+
823| TWOFISH IV |
824| |
825+-----+-----+-----+-----+-----+-----+-----+-----+
826 ]]></artwork>
827 <!-- <postamble>which is a very simple example.</postamble>-->
828 </figure>
829
830 <t>
831 The keys and IVs are used for a CFB128-AES-256 and
832 CFB128-TWOFISH-256 chained symmetric cipher. Both ciphers are used in
833 Cipher FeedBack (CFB) mode <xref target="RFC3826" />.
834 </t>
835 <artwork name="" type="" align="left" alt=""><![CDATA[
836RDATA := AES(K[0:31], IV[0:15],
837 TWOFISH(K[32:63], IV[16:31], BDATA))
838BDATA := TWOFISH(K[32:63], IV[16:31],
839 AES(K[0:31], IV[0:15], RDATA))
840 ]]></artwork>
841 </section>
842 </section>
843 <section anchor="encoding" numbered="true" toc="default">
844 <name>Internationalization and Character Encoding</name>
845 <t>
846 All labels in GNS are encoded in UTF-8 <xref target="RFC3629" />.
847 This does not include any DNS names found in DNS records, such as CNAME
848 records, which are internationalized through the IDNA specifications
849 <xref target="RFC5890" />.
850 </t>
851 </section>
852 <section anchor="resolution" numbered="true" toc="default">
853 <name>Name Resolution</name>
854 <t>
855 Names in GNS are resolved by recursively querying the DHT record storage.
856 In the following, we define how resolution is initiated and each
857 iteration in the resolution is processed.
858 </t>
859 <t>
860 GNS resolution of a name must start in a given starting zone indicated using
861 a zone public key.
862 Details on how the starting zone may be determined is discussed in
863 <xref target="governance" />.
864 </t>
865 <t>
866 When GNS name resolution is requested, a desired record type MAY be
867 provided by the client.
868 The GNS resolver will use the desired record type to guide
869 processing, for example by providing conversion of VPN records to A
870 or AAAA records, if that is desired.
871
872 However, filtering of record sets according to the required record
873 types MUST still be done by the client after the resource record set
874 is retrieved.
875 </t>
876 <section anchor="recursion" numbered="true" toc="default">
877 <name>Recursion</name>
878 <t>
879 In each step of the recursive name resolution, there is an
880 authoritative zone zk and a name to resolve. The name may be empty.
881 Initially, the authoritative zone is the start zone. If the name
882 is empty, it is interpreted as the apex label "@".
883 </t>
884 <t>
885 From here, the following steps are recursively executed, in order:
886 </t>
887 <ol>
888 <li>Extract the right-most label from the name to look up.</li>
889 <li>Calculate q using the label and zk as defined in
890 <xref target="blinding" />.</li>
891 <li>Perform a DHT query GET(q) to retrieve the RRBLOCK.</li>
892 <li>Verify and process the RRBLOCK and decrypt the BDATA contained
893 in it as defined in <xref target="recordencryption" />.</li>
894 </ol>
895 <t>
896 Upon receiving the RRBLOCK from the DHT, apart from verifying the
897 provided signature, the resolver MUST check that the authoritative
898 zone key was used to sign the record:
899 The derived zone key "h*zk" MUST match the public key provided in
900 the RRBLOCK, otherwise the RRBLOCK MUST be ignored and the DHT lookup
901 GET(q) MUST continue.
902 </t>
903 </section>
904 <section anchor="record_processing" numbered="true" toc="default">
905 <name>Record Processing</name>
906 <t>
907 Record processing occurs at the end of a single recursion. We assume
908 that the RRBLOCK has been cryptographically verified and decrypted.
909 At this point, we must first determine if we have received a valid
910 record set in the context of the name we are trying to resolve:
911 </t>
912 <ol>
913 <li>
914 Case 1:
915 If the remainder of the name to resolve is empty and the record set
916 does not consist of a PKEY, CNAME or DNS2GNS record, the record set
917 is the result and the recursion is concluded.
918 </li>
919 <li>
920 Case 2:
921 If the name to be resolved is of the format
922 "_SERVICE._PROTO" and the record set contains one or more matching BOX
923 records, the records in the BOX records are the result and the recusion
924 is concluded (<xref target="box_processing" />).
925 </li>
926 <li>
927 Case 3:
928 If the remainder of the name to resolve is not empty and
929 does not match the "_SERVICE._PROTO" syntax, then the current record set
930 MUST consist of a single PKEY record (<xref target="pkey_processing" />),
931 a single CNAME record (<xref target="cname_processing" />),
932 or one or more GNS2DNS records (<xref target="gns2dns_processing" />),
933 which are processed as described in the respective sections below.
934 The record set may include any number of supplemental records.
935 Otherwise, resolution fails
936 and the resolver MUST return an empty record set.
937
938 Finally, after the recursion terminates, the client preferences
939 for the record type SHOULD be considered. If a VPN record is found
940 and the client requests an A or AAAA record, the VPN record
941 SHOULD be converted (<xref target="vpn_processing" />)
942 if possible.
943 </li>
944 </ol>
945 <section anchor="pkey_processing" numbered="true" toc="default">
946 <name>PKEY</name>
947 <t>
948 When the resolver encounters a PKEY record and the remainder of
949 the name is not empty, resolution continues
950 recursively with the remainder of the name in the
951 GNS zone specified in the PKEY record.
952 </t>
953 <t>
954 If the remainder of the name to resolve is empty and we have
955 received a record set containing only a single PKEY record, the
956 recursion is continued with the PKEY as authoritative zone and
957 the empty apex label "@" as remaining name, except in the case
958 where the desired record type is PKEY, in which case the PKEY
959 record is returned and the resolution is concluded without
960 resolving the empty apex label.
961 </t>
962 </section>
963 <section anchor="gns2dns_processing" numbered="true" toc="default">
964 <name>GNS2DNS</name>
965 <t>
966 When a resolver encounters one or more GNS2DNS records and the remaining name
967 is empty and the desired record type is GNS2DNS, the GNS2DNS
968 records are returned.
969 </t>
970 <t>
971 Otherwise, it is expected that the resolver first resolves the
972 IP(s) of the specified DNS name server(s). GNS2DNS records MAY
973 contain numeric IPv4 or IPv6 addresses, allowing the resolver to
974 skip this step.
975 The DNS server names may themselves be names in GNS or DNS.
976 If the DNS server name ends in ".+", the rest of the name is to be
977 interpreted relative to the zone of the GNS2DNS record.
978 If the DNS server name ends in ".&lt;Base32(zk)&gt;", the DNS
979 server name is to be resolved against the GNS zone zk.
980 </t>
981 <t>
982 Multiple GNS2DNS records may be stored under the same label,
983 in which case the resolver MUST try all of them.
984 The resolver MAY try them in any order or even in parallel.
985 If multiple GNS2DNS records are present, the DNS name MUST be
986 identical for all of them, if not the resolution fails and an
987 emtpy record set is returned as the record set is invalid.
988 </t>
989 <t>
990 Once the IP addresses of the DNS servers have been determined,
991 the DNS name from the GNS2DNS record is appended
992 to the remainder of the name to be resolved, and
993 resolved by querying the DNS name server(s). As the DNS servers
994 specified are possibly authoritative DNS servers, the GNS resolver MUST
995 support recursive resolution and MUST NOT delegate this to the
996 authoritative DNS servers.
997 The first successful recursive name resolution result
998 is returned to the client.
999 In addition, the resolver returns the queried DNS name as a
1000 supplemental LEHO record (<xref target="gnsrecords_leho" />) with a
1001 relative expiration time of one hour.
1002 </t>
1003 <t>
1004 GNS resolvers SHOULD offer a configuration
1005 option to disable DNS processing to avoid information leakage
1006 and provide a consistent security profile for all name resolutions.
1007 Such resolvers would return an empty record set upon encountering
1008 a GNS2DNS record during the recursion. However, if GNS2DNS records
1009 are encountered in the record set for the apex and a GNS2DNS record
1010 is expicitly requested by the application, such records MUST
1011 still be returned, even if DNS support is disabled by the
1012 GNS resolver configuration.
1013 </t>
1014 </section>
1015 <section anchor="cname_processing" numbered="true" toc="default">
1016 <name>CNAME</name>
1017 <t>
1018 If a CNAME record is encountered, the canonical name is
1019 appended to the remaining name, except if the remaining name
1020 is empty and the desired record type is CNAME, in which case
1021 the resolution concludes with the CNAME record.
1022 If the canonical name ends in ".+",
1023 resolution continues in GNS with the new name in the
1024 current zone. Otherwise, the resulting name is resolved via the
1025 default operating system name resolution process.
1026 This may in turn again trigger a GNS resolution process depending
1027 on the system configuration.
1028 <!-- Note: this permits non-DNS resolvers to be triggered via NSS! -->
1029 </t>
1030 <t>
1031 The recursive DNS resolution process may yield a CNAME as well
1032 which in turn may either point into the DNS or GNS namespace
1033 (if it ends in a ".&lt;Base32(zk)&gt;").
1034 In order to prevent infinite loops, the resolver MUST
1035 implement loop detections or limit the number of recursive
1036 resolution steps.
1037 If the last CNAME was a DNS name, the resolver returns the DNS name
1038 as a supplemental LEHO record (<xref target="gnsrecords_leho" />)
1039 with a relative expiration time of one hour.
1040 <!-- Note: Martin: do we actually implement this in GNS today?
1041 Seems rather tricky to detect if we go via NSS... -->
1042 </t>
1043 </section>
1044 <section anchor="box_processing" numbered="true" toc="default">
1045 <name>BOX</name>
1046 <t>
1047 When a BOX record is received, a GNS resolver must unbox it if the
1048 name to be resolved continues with "_SERVICE._PROTO".
1049 Otherwise, the BOX record is to be left untouched. This way, TLSA
1050 (and SRV) records do not require a separate network request, and
1051 TLSA records become inseparable from the corresponding address
1052 records.
1053 </t>
1054 </section>
1055 <section anchor="vpn_processing" numbered="true" toc="default">
1056 <name>VPN</name>
1057 <t>
1058 At the end of the recursion,
1059 if the queried record type is either A or AAAA and the retrieved
1060 record set contains at least one VPN record, the resolver SHOULD
1061 open a tunnel and return the IPv4 or IPv6 tunnel address,
1062 respectively.
1063 The type of tunnel depends on the contents of the VPN record data.
1064 The VPN record MUST be returned if the resolver implementation
1065 does not support setting up a tunnnel.
1066 </t>
1067 </section>
1068 <section anchor="nick_processing" numbered="true" toc="default">
1069 <name>NICK</name>
1070 <t>
1071 NICK records are only relevant to the recursive resolver
1072 if the record set in question is the final result which is to
1073 be returned to the client. The encountered NICK records may either
1074 be supplemental (see <xref target="rrecords"/>) or
1075 non-supplemental.
1076 If the NICK record is supplemental, the resolver only returns the
1077 record set if one of the non-supplemental records matches the
1078 queried record type.
1079 </t>
1080 <t>
1081 The differentiation between a supplemental and non-supplemental
1082 NICK record allows the client to match the record to the
1083 authoritative zone. Consider the following example:
1084 </t>
1085 <figure>
1086 <artwork name="" type="" align="left" alt=""><![CDATA[
1087Query: alice.example (type=A)
1088Result:
1089A: 192.0.2.1
1090NICK: eve
1091 ]]></artwork>
1092 </figure>
1093 <t>
1094 In this example, the returned NICK record is non-supplemental.
1095 For the client, this means that the NICK belongs to the zone
1096 "alice.doe" and is published under the empty label along with an A
1097 record. The NICK record should be interpreted as: The zone defined by
1098 "alice.doe" wants to be referred to as "eve".
1099 In contrast, consider the following:
1100 </t>
1101 <figure>
1102 <artwork name="" type="" align="left" alt=""><![CDATA[
1103Query: alice.example (type=AAAA)
1104Result:
1105AAAA: 2001:DB8::1
1106NICK: john (Supplemental)
1107 ]]></artwork>
1108 </figure>
1109 <t>
1110 In this case, the NICK record is marked as supplemental. This means that
1111 the NICK record belongs to the zone "doe" and is published under the
1112 label "alice" along with an A record. The NICK record should be
1113 interpreted as: The zone defined by "doe" wants to be referred to as
1114 "john". This distinction is likely useful for other records published as
1115 supplemental.
1116 </t>
1117
1118
1119 </section>
1120 </section>
1121 </section>
1122 <section anchor="revocation" numbered="true" toc="default">
1123 <name>Zone Revocation</name>
1124 <t>
1125 Whenever a recursive resolver encounters a new GNS zone, it MUST
1126 check against the local revocation list whether the respective
1127 zone key has been revoked. If the zone key was revoked, the
1128 resolution MUST fail with an empty result set.
1129 </t>
1130 <t>
1131 In order to revoke a zone key, a signed revocation object SHOULD be
1132 published.
1133 This object MUST be signed using the private zone key.
1134 The revocation object is flooded in the overlay network. To prevent
1135 flooding attacks, the revocation message MUST contain a proof of work
1136 (PoW).
1137 The revocation message including the PoW MAY be calculated
1138 ahead of time to support timely revocation.
1139 </t>
1140 <t>
1141 For all occurences below, "Argon2id" is the Password-based Key
1142 Derivation Function as defined in <xref target="Argon2" />. For the
1143 PoW calculations the algorithm is instantiated with the
1144 following parameters:
1145 </t>
1146 <dl>
1147 <dt>S</dt>
1148 <dd>The salt. Fixed 16-octet string: "GnsRevocationPow".</dd>
1149 <dt>t</dt>
1150 <dd>Number of iterations: 3</dd>
1151 <dt>m</dt>
1152 <dd>Memory size in KiB: 1024</dd>
1153 <dt>T</dt>
1154 <dd>Output length of hash in bytes: 64</dd>
1155 <dt>p</dt>
1156 <dd>Parallelization parameter: 1</dd>
1157 <dt>v</dt>
1158 <dd>Algorithm version: 0x13</dd>
1159 <dt>y</dt>
1160 <dd>Algorithm type (Argon2id): 2</dd>
1161 <dt>X</dt><dd>Unused</dd>
1162 <dt>K</dt><dd>Unused</dd>
1163 </dl>
1164 <t>
1165 The following is the message string "P" on which the PoW is
1166 calculated:
1167 </t>
1168 <figure anchor="figure_revocation">
1169 <artwork name="" type="" align="left" alt=""><![CDATA[
11700 8 16 24 32 40 48 56
1171+-----+-----+-----+-----+-----+-----+-----+-----+
1172| POW |
1173+-----------------------------------------------+
1174| TIMESTAMP |
1175+-----------------------------------------------+
1176| PUBLIC KEY |
1177| |
1178| |
1179| |
1180+-----+-----+-----+-----+-----+-----+-----+-----+
1181 ]]></artwork>
1182 </figure>
1183 <t>where:</t>
1184 <dl>
1185 <dt>POW</dt>
1186 <dd>
1187 A 64-bit solution to the PoW. In network byte order.
1188 </dd>
1189 <dt>TIMESTAMP</dt>
1190 <dd>
1191 denotes the absolute 64-bit date when the revocation was computed.
1192 In microseconds since midnight (0 hour), January 1, 1970 in network
1193 byte order.
1194 </dd>
1195 <dt>PUBLIC KEY</dt>
1196 <dd>
1197 is the 256-bit public key "zk" of the zone which is being revoked and
1198 the key to be used to verify SIGNATURE. The
1199 wire format of this value is defined in <xref target="RFC8032" />,
1200 Section 5.1.5.
1201 </dd>
1202 </dl>
1203 <t>
1204 Traditionally, PoW schemes require to find a "POW" such that
1205 at least D leading zeroes are found in the hash result.
1206 D is then referred to as the "difficulty" of the PoW.
1207 In order to reduce the variance in time it takes to calculate the
1208 PoW, we require that a number "Z" different PoWs must be
1209 found that on average have "D" leading zeroes.
1210 </t>
1211 <t>
1212 The resulting proofs may then published and disseminated. The concrete
1213 dissemination and publication methods are out of scope of this
1214 document. Given an average difficulty of "D", the proofs have an
1215 expiration time of EPOCH. With each additional bit difficulty, the
1216 lifetime of the proof is prolonged for another EPOCH.
1217 Consequently, by calculating a more difficult PoW, the lifetime of the
1218 proof can be increased on demand by the zone owner.
1219 </t>
1220 <t>
1221 The parameters are defined as follows:
1222 </t>
1223 <dl>
1224 <dt>Z</dt>
1225 <dd>The number of PoWs required is fixed at 32.</dd>
1226 <dt>D</dt>
1227 <dd>The difficulty is fixed at 25.</dd>
1228 <dt>EPOCH</dt>
1229 <dd>A single epoch is fixed at 365 days.</dd>
1230 </dl>
1231 <t>
1232 Given that proof has been found, a revocation data object is defined
1233 as follows:
1234 </t>
1235 <figure anchor="figure_revocationdata">
1236 <artwork name="" type="" align="left" alt=""><![CDATA[
12370 8 16 24 32 40 48 56
1238+-----+-----+-----+-----+-----+-----+-----+-----+
1239| TIMESTAMP |
1240+-----+-----+-----+-----+-----+-----+-----+-----+
1241| TTL |
1242+-----+-----+-----+-----+-----+-----+-----+-----+
1243| POW_0 |
1244+-----+-----+-----+-----+-----+-----+-----+-----+
1245| ... |
1246+-----+-----+-----+-----+-----+-----+-----+-----+
1247| POW_Z-1 |
1248+-----------------------------------------------+
1249| SIGNATURE |
1250| |
1251| |
1252| |
1253| |
1254| |
1255| |
1256| |
1257+-----+-----+-----+-----+-----+-----+-----+-----+
1258| PUBLIC KEY |
1259| |
1260| |
1261| |
1262+-----+-----+-----+-----+-----+-----+-----+-----+
1263 ]]></artwork>
1264 </figure>
1265 <t>where:</t>
1266 <dl>
1267 <dt>TIMESTAMP</dt>
1268 <dd>
1269 denotes the absolute 64-bit date when the revocation was computed.
1270 In microseconds since midnight (0 hour), January 1, 1970 in network
1271 byte order. This is the same value as the timestamp used in the
1272 individual PoW calculations.
1273 </dd>
1274 <dt>TTL</dt>
1275 <dd>
1276 denotes the relative 64-bit time to live of of the record in
1277 microseconds also in network byte order. This field is informational
1278 for a verifier. The verifier may discard revocation if the TTL
1279 indicates that it is already expired. However, the actual TTL of the
1280 revocation must be determined by examining the leading zeros in the
1281 proof of work calculation.
1282 </dd>
1283 <dt>POW_i</dt>
1284 <dd>
1285 The values calculated as part of the PoW, in network byte order.
1286 Each POW_i MUST be unique in the set of POW values.
1287 To facilitate fast verification
1288 of uniqueness, the POW values must be given in strictly
1289 monotonically increasing order in the message.
1290 </dd>
1291 <dt>SIGNATURE</dt>
1292 <dd>
1293 A 512-bit ECDSA deterministic signature compliant with
1294 <xref target="RFC6979" /> over the public zone zk of the zone
1295 which is revoked and corresponds to the key used in the PoW.
1296 The signature is created using the private zone key "d" (see
1297 <xref target="zones" />).
1298 </dd>
1299 <dt>PUBLIC KEY</dt>
1300 <dd>
1301 is the 256-bit public key "zk" of the zone which is being revoked and
1302 the key to be used to verify SIGNATURE. The
1303 wire format of this value is defined in <xref target="RFC8032" />,
1304 Section 5.1.5.
1305 </dd>
1306 </dl>
1307 <t>
1308 The signature over the public key covers a 32 bit pseudo header
1309 conceptually prefixed to the public key. The pseudo header includes
1310 the key length and signature purpose:
1311 </t>
1312 <figure anchor="figure_revsigwithpseudo">
1313 <artwork name="" type="" align="left" alt=""><![CDATA[
13140 8 16 24 32 40 48 56
1315+-----+-----+-----+-----+-----+-----+-----+-----+
1316| SIZE (0x30) | PURPOSE (0x03) |
1317+-----+-----+-----+-----+-----+-----+-----+-----+
1318| PUBLIC KEY |
1319| |
1320| |
1321| |
1322+-----+-----+-----+-----+-----+-----+-----+-----+
1323| TIMESTAMP |
1324+-----+-----+-----+-----+-----+-----+-----+-----+
1325 ]]></artwork>
1326 </figure>
1327 <t>where:</t>
1328 <dl>
1329 <dt>SIZE</dt>
1330 <dd>
1331 A 32-bit value containing the length of the signed data in bytes
1332 (48 bytes) in network byte order.
1333 </dd>
1334 <dt>PURPOSE</dt>
1335 <dd>
1336 A 32-bit signature purpose flag. This field MUST be 3 (in network
1337 byte order).
1338 </dd>
1339 <dt>PUBLIC KEY / TIMESTAMP</dt>
1340 <dd>Both values as defined in the revocation data object above.</dd>
1341 </dl>
1342 <t>
1343 In order to verify a revocation the following steps must be taken,
1344 in order:
1345 </t>
1346 <ol>
1347 <li>The current time MUST be between TIMESTAMP and
1348 TIMESTAMP+TTL.</li>
1349 <li>The signature MUST match the public key.</li>
1350 <li>The set of POW values MUST NOT contain duplicates.</li>
1351 <li>The average number of leading zeroes resulting from the provided
1352 POW values D' MUST be greater than D.</li>
1353 <li>The validation period (TTL) of the revocation is calculated as
1354 (D'-D) * EPOCH * 1.1. The EPOCH is extended by
1355 10% in order to deal with unsynchronized clocks.
1356 The TTL added on top of the TIMESTAMP yields the
1357 expiration date.</li>
1358 </ol>
1359 </section>
1360 <section anchor="governance" numbered="true" toc="default">
1361 <name>Determining the Root Zone and Zone Governance</name>
1362 <t>
1363 The resolution of a GNS name must start in a given start zone
1364 indicated to the resolver using any public zone key.
1365 The local resolver may have a local start zone configured/hard-coded
1366 which points to a local or remote start zone key.
1367 A resolver client may also determine the start zone from the
1368 suffix of the name given for resolution or using information
1369 retrieved out of band.
1370 The governance model of any zone is at the sole discretion
1371 of the zone owner. However, the choice of start zone(s) is at the sole
1372 discretion of the local system administrator or user.
1373 </t>
1374 <t>
1375 This is an important distinguishing factor from the Domain Name System
1376 where root zone governance is centralized at the Internet Corporation
1377 for Assigned Names and Numbers (ICANN).
1378 In DNS terminology, GNS roughly follows the idea of a hyper-hyper
1379 local root zone deployment, with the difference that it is not
1380 expected that all deployments use the same local root zone.
1381 </t>
1382 <t>
1383 In the following, we give examples how a local client resolver SHOULD
1384 discover the start zone. The process given is not exhaustive and
1385 clients MAY suppliement it with other mechanisms or ignore it if the
1386 particular application requires a different process.
1387 </t>
1388 <t>
1389 GNS clients SHOULD first try to interpret the top-level domain of
1390 a GNS name as a zone key.
1391 For example. if the top-level domain is a Base32-encoded public zone
1392 key "zk", the root zone of the resolution process is implicitly given
1393 by the name:
1394 </t>
1395 <artwork name="" type="" align="left" alt=""><![CDATA[
1396Example name: www.example.<Base32(zk)>
1397=> Root zone: zk
1398=> Name to resolve from root zone: www.example
1399 ]]></artwork>
1400 <t>
1401 In GNS, users MAY own and manage their own zones.
1402 Each local zone SHOULD be associated with a single GNS label,
1403 but users MAY choose to use longer names consisting of
1404 multiple labels.
1405 If the name of a locally managed zone matches the suffix
1406 of the name to be resolved,
1407 resolution SHOULD start from the respective local zone:
1408 </t>
1409 <artwork name="" type="" align="left" alt=""><![CDATA[
1410Example name: www.example.org
1411Local zones:
1412fr = (d0,zk0)
1413gnu = (d1,zk1)
1414com = (d2,zk2)
1415...
1416=> Entry zone: zk1
1417=> Name to resolve from entry zone: www.example
1418 ]]></artwork>
1419 <t>
1420 Finally, additional "suffix to zone" mappings MAY be configured.
1421 Suffix to zone key mappings SHOULD be configurable through a local
1422 configuration file or database by the user or system administrator.
1423 The suffix MAY consist of multiple GNS labels concatenated with a
1424 ".". If multiple suffixes match the name to resolve, the longest
1425 matching suffix MUST BE used. The suffix length of two results
1426 cannot be equal, as this would indicate a misconfiguration.
1427 If both a locally managed zone and a configuration entry exist
1428 for the same suffix, the locally managed zone MUST have priority.
1429 </t>
1430 <artwork name="" type="" align="left" alt=""><![CDATA[
1431Example name: www.example.org
1432Local suffix mappings:
1433gnu = zk0
1434example.org = zk1
1435example.com = zk2
1436...
1437=> Entry zone: zk1
1438=> Name to resolve from entry zone: www
1439 ]]></artwork>
1440 </section>
1441 <section anchor="security" numbered="true" toc="default">
1442 <name>Security Considerations</name>
1443 <section anchor="security_crypto" numbered="true" toc="default">
1444 <name>Cryptography</name>
1445 <t>
1446 The security of cryptographic systems depends on both the strength of
1447 the cryptographic algorithms chosen and the strength of the keys used
1448 with those algorithms. The security also depends on the engineering
1449 of the protocol used by the system to ensure that there are no
1450 non-cryptographic ways to bypass the security of the overall system.
1451 </t>
1452 <t>
1453 This document concerns itself with the selection of cryptographic
1454 algorithms for use in GNS.
1455 The algorithms identified in this document are not known to be
1456 broken (in the cryptographic sense) at the current time, and
1457 cryptographic research so far leads us to believe that they are
1458 likely to remain secure into the foreseeable future. However, this
1459 isn't necessarily forever, and it is expected that new revisions of
1460 this document will be issued from time to time to reflect the current
1461 best practices in this area.
1462 </t>
1463 <t>
1464 GNS uses ECDSA over Curve25519. This is an unconventional choice,
1465 as ECDSA is usually used with other curves. However, traditional
1466 ECDSA curves are problematic for a range of reasons described in
1467 the Curve25519 and EdDSA papers. Using EdDSA directly is also
1468 not possible, as a hash function is used on the private key which
1469 destroys the linearity that the GNU Name System depends upon.
1470 We are not aware of anyone suggesting that using Curve25519 instead
1471 of another common curve of similar size would lower the security of
1472 ECDSA. GNS uses 256-bit curves because that way the encoded (public)
1473 keys fit into a single DNS label, which is good for usability.
1474 </t>
1475 <t>
1476 In terms of crypto-agility, whenever the need for an updated cryptographic
1477 scheme arises to replace ECDSA over Curve25519 it may simply be introduced
1478 through a new record type. Such a new record type may then replace
1479 the PKEY record type for future records. The old record type remains
1480 and zones can iteratively migrate to the updated zone keys.
1481 </t>
1482 </section>
1483 <section anchor="security_abuse" numbered="true" toc="default">
1484 <name>Abuse mitigation</name>
1485 <t>
1486 GNS names are UTF-8 strings. Consequently, GNS faces similar issues
1487 with respect to name spoofing as DNS does for internationalized
1488 domain names.
1489 In DNS, attackers may register similar sounding or looking
1490 names (see above) in order to execute phishing attacks.
1491 GNS zone administrators must take into account this attack vector and
1492 incorporate rules in order to mitigate it.
1493 </t>
1494 <t>
1495 Further, DNS can be used to combat illegal content on the internet
1496 by having the respective domains seized by authorities.
1497 However, the same mechanisms can also be abused in order to impose
1498 state censorship, which ist one of the motivations behind GNS.
1499 Hence, such a seizure is, by design, difficult to impossible in GNS.
1500 In particular, GNS does not support WHOIS (<xref target="RFC3912" />).
1501 </t>
1502 </section>
1503 <section anchor="security_keymanagement" numbered="true" toc="default">
1504 <name>Zone management</name>
1505 <t>
1506 In GNS, zone administrators need to manage and protect their zone
1507 keys. Once a zone key is lost it cannot be recovered. Once it is
1508 compromised it cannot be revoked (unless a revocation message was
1509 pre-calculated and is still available).
1510 Zone administrators, and for GNS this includes end-users, are
1511 required to responsibly and dilligently protect their cryptographic
1512 keys. Offline signing is in principle possible, but GNS does not
1513 support separate zone signing and key-signing keys
1514 (as in <xref target="RFC6781" />) in order to provide usable security.
1515 </t>
1516 <t>
1517 Similarly, users are required to manage their local root zone.
1518 In order to ensure integrity and availability or names, users must
1519 ensure that their local root zone information is not compromised or
1520 outdated.
1521 It can be expected that the processing of zone revocations and an
1522 initial root zone is provided with a GNS client implementation
1523 ("drop shipping").
1524 Extension and customization of the zone is at the full discretion of
1525 the user.
1526 </t>
1527 </section>
1528 <section anchor="security_dht" numbered="true" toc="default">
1529 <name>Impact of underlying DHT</name>
1530 <t>
1531 This document does not specifiy the properties of the underlying
1532 distributed hash table (DHT) which is required by any GNS
1533 implementation. For implementors, it is important to note that
1534 the properties of the DHT are directly inherited by the
1535 GNS implementation. This includes both security as well as
1536 other non-functional properties such as scalability and performance.
1537 Implementors should take great care when selecting or implementing
1538 a DHT for use in a GNS implementation.
1539 DHTs with string security and performance guarantees exist
1540 <xref target="R5N"/>.
1541 It should also be taken into consideration that GNS implementations
1542 which build upon different DHT overlays are unlikely to be
1543 interoperable with each other.
1544 </t>
1545 </section>
1546 <section anchor="security_rev" numbered="true" toc="default">
1547 <name>Revocations</name>
1548 <t>
1549 Zone administrators are advised to pre-generate zone revocations
1550 and securely store the revocation information in case the zone
1551 key is lost, compromised or replaced in the furture.
1552 Pre-calculated revocations may become invalid due to expirations
1553 or protocol changes such as epoch adjustments.
1554 Consequently, implementors and users must make precautions in order
1555 to manage revocations accordingly.
1556 </t>
1557 <t>
1558 Revocation payloads do NOT include a 'new' key for key replacement.
1559 Inclusion of such a key would have two major disadvantages:
1560 </t>
1561 <t>
1562 If revocation is used after a private key was compromised,
1563 allowing key replacement would be dangerous: if an
1564 adversary took over the private key, the adversary could then
1565 broadcast a revocation with a key replacement. For the replacement,
1566 the compromised owner would have no chance to issue even a
1567 revocation. Thus, allowing a revocation message to replace a private
1568 key makes dealing with key compromise situations worse.
1569 </t>
1570 <t>
1571 Sometimes, key revocations are used with the objective of changing
1572 cryptosystems. Migration to another cryptosystem by replacing keys
1573 via a revocation message would only be secure as long as both
1574 cryptosystems are still secure against forgery. Such a planned,
1575 non-emergency migration to another cryptosystem should be done by
1576 running zones for both ciphersystems in parallel for a while. The
1577 migration would conclude by revoking the legacy zone key only once
1578 it is deemed no longer secure, and hopefully after most users have
1579 migrated to the replacement.
1580 </t>
1581 </section>
1582 </section>
1583 <section anchor="gana" numbered="true" toc="default">
1584 <name>GANA Considerations</name>
1585 <t>
1586 GANA is requested to create an "GNU Name System Record Types" registry.
1587 The registry shall record for each entry:
1588 </t>
1589 <ul>
1590 <li>Name: The name of the record type (case-insensitive ASCII
1591 string, restricted to alphanumeric characters</li>
1592 <li>Number: 32-bit, above 65535</li>
1593 <li>Comment: Optionally, a brief English text describing the purpose of
1594 the record type (in UTF-8)</li>
1595 <li>Contact: Optionally, the contact information of a person to contact for
1596 further information</li>
1597 <li>References: Optionally, references describing the record type
1598 (such as an RFC)</li>
1599 </ul>
1600 <t>
1601 The registration policy for this sub-registry is "First Come First
1602 Served", as described in <xref target="RFC8126"/>.
1603 GANA is requested to populate this registry as follows:
1604 </t>
1605 <figure anchor="figure_rrtypenums">
1606 <artwork name="" type="" align="left" alt=""><![CDATA[
1607Number | Name | Contact | References | Description
1608-------+---------+---------+------------+-------------------------
160965536 | PKEY | N/A | [This.I-D] | GNS zone delegation
161065537 | NICK | N/A | [This.I-D] | GNS zone nickname
161165538 | LEHO | N/A | [This.I-D] | GNS legacy hostname
161265539 | VPN | N/A | [This.I-D] | VPN resolution
161365540 | GNS2DNS | N/A | [This.I-D] | Delegation to DNS
161465541 | BOX | N/A | [This.I-D] | Boxed record
1615 ]]></artwork>
1616 </figure>
1617 <t>
1618 GANA is requested to amend the "GNUnet Signature Purpose" registry
1619 as follows:
1620 </t>
1621 <figure anchor="figure_purposenums">
1622 <artwork name="" type="" align="left" alt=""><![CDATA[
1623Purpose | Name | References | Description
1624--------+-----------------+------------+--------------------------
1625 3 | GNS_REVOCATION | [This.I-D] | GNS zone key revocation
1626 15 | GNS_RECORD_SIGN | [This.I-D] | GNS record set signature
1627 ]]></artwork>
1628 </figure>
1629 </section>
1630 <!-- gana -->
1631 <section>
1632 <name>Test Vectors</name>
1633 <t>
1634 The following represents a test vector for a record set with a DNS
1635 record of type "A" as well as a GNS record of type "PKEY"
1636 under the label "test".
1637 </t>
1638 <artwork name="" type="" align="left" alt="">
1639 <![CDATA[
1640Zone private key (d, little-endian scalar):
16413015471ecb45455b5e9df50ff416b3d53aa6db6cafec858449f788142d091d41
1642
1643Zone public key (zk):
1644bf06e687a291a509b6326bb6394dd6ed3ff9e5eb78ea5752ed0eba0807023a33
1645
1646Label: test
1647RRCOUNT: 2
1648
1649Record #0
1650EXPIRATION: 1590482415557079
1651DATA_SIZE: 4
1652TYPE: 1
1653FLAGS: 0
1654DATA:
165501020304
1656
1657Record #1
1658EXPIRATION: 1590482415557079
1659DATA_SIZE: 32
1660TYPE: 65536
1661FLAGS: 2
1662DATA:
1663814fbb06b17f4ecf
1664d098700619179f9d
16654aef24465bd6958a
1666e4ed01cd024b1856
1667
1668RDATA:
16690005a6890b6699d7
16700000000400000001
16710000000001020304
16720005a6890b6699d7
16730000002000010000
167400000002814fbb06
1675b17f4ecfd0987006
167619179f9d4aef2446
16775bd6958ae4ed01cd
1678024b185600000000
16790000000000000000
16800000000000000000
16810000000000000000
16820000000000000000
16830000000000000000
16840000000000000000
1685
1686BDATA:
16879f471611a5c06fc2
1688c9ad33f642dd315c
1689f8fc675aed23e8a1
1690d19a5bad657557fe
16916e1d50709860593e
16925376c30f6f22daac
16935293986b7444476d
1694b8f289f5537da168
1695dc81cba256d8401b
1696642dbe6a24346e11
16979148ade8acb4d5e5
1698cef5eb5ad1e3b95d
1699d143123d387b8df0
1700ba4e2d75a9eb94a4
1701f3250b975fee90e9
1702558bb9e1e009ca46
1703b7a066dd
1704
1705RRBLOCK:
170608180a871b910ade
1707a1125a1030d0f269
1708069e5731c90ad0d0
1709cfa10bf61b3f0c79
17100833b515d4c746e6
17114a7261947bfb6429
171221200bb97a96292d
17136abefab1197f7e4e
1714b399c628a71d3627
1715d64a2bd66080f64d
171691c0120ab14601d8
171718de23c8da82b80b
1718000000940000000f
17190005a6890b6699d7
17209f471611a5c06fc2
1721c9ad33f642dd315c
1722f8fc675aed23e8a1
1723d19a5bad657557fe
17246e1d50709860593e
17255376c30f6f22daac
17265293986b7444476d
1727b8f289f5537da168
1728dc81cba256d8401b
1729642dbe6a24346e11
17309148ade8acb4d5e5
1731cef5eb5ad1e3b95d
1732d143123d387b8df0
1733ba4e2d75a9eb94a4
1734f3250b975fee90e9
1735558bb9e1e009ca46
1736b7a066dd
1737 ]]>
1738 </artwork>
1739 <t>
1740 The following is an example revocation for a zone:
1741 </t>
1742 <artwork name="" type="" align="left" alt="">
1743 <![CDATA[
1744Zone private key (d, little-endian scalar):
174590ea2a95cb9ef482b45817dc45b805cae00f387022a065a3674f41ad15173c63
1746
1747Zone public key (zk):
17484ac1e51d9a585a9ad9fb0dfac2be100aee83f0cc79c4c5ea8f3eb8afd9092fa5
1749
1750Difficulty (5 base difficulty + 2 epochs): 7
1751
1752Proof:
17530005a5fd368978f4
17540000395d1827c000
1755e23f657bc47ec853
1756e23f657bc47ec9d8
1757e23f657bc47ecaec
1758e23f657bc47ecb29
1759e23f657bc47ecc00
1760e23f657bc47ecc79
1761e23f657bc47ece83
1762e23f657bc47ecfc6
1763e23f657bc47ecfc8
1764e23f657bc47ecfd5
1765e23f657bc47ed02b
1766e23f657bc47ed03b
1767e23f657bc47ed0ff
1768e23f657bc47ed241
1769e23f657bc47ed264
1770e23f657bc47ed2e5
1771e23f657bc47ed343
1772e23f657bc47ed348
1773e23f657bc47ed45e
1774e23f657bc47ed480
1775e23f657bc47ed49a
1776e23f657bc47ed564
1777e23f657bc47ed565
1778e23f657bc47ed5b6
1779e23f657bc47ed5de
1780e23f657bc47ed5e0
1781e23f657bc47ed77f
1782e23f657bc47ed800
1783e23f657bc47ed80c
1784e23f657bc47ed817
1785e23f657bc47ed82c
1786e23f657bc47ed8a6
17870396020c831a5405
1788cee6c38842209191
1789c8db799dbe81e0dc
1790f6dbd4f91c257ae2
17910079e7fd1cd31cc2
17924cd9a52831d5ec30
1793f10e22e5a6dd9065
179418746cfce2095610
17954ac1e51d9a585a9a
1796d9fb0dfac2be100a
1797ee83f0cc79c4c5ea
17988f3eb8afd9092fa5
1799 ]]>
1800 </artwork>
1801 </section>
1802 </middle>
1803 <back>
1804 <references>
1805 <name>Normative References</name>
1806
1807 &RFC1034;
1808 &RFC1035;
1809 &RFC2782;
1810 &RFC2119;
1811 &RFC3629;
1812 &RFC3826;
1813 &RFC3912;
1814 &RFC5869;
1815 &RFC5890;
1816 &RFC5891;
1817 &RFC6781;
1818 &RFC6895;
1819 &RFC6979;
1820 &RFC7748;
1821 &RFC8032;
1822 &RFC8126;
1823
1824 <reference anchor="TWOFISH">
1825 <front>
1826 <title>
1827 The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition
1828 </title>
1829 <author initials="B." surname="Schneier" fullname="B. Schneier">
1830 <organization/>
1831 </author>
1832 <date year="1999" month="March"/>
1833 </front>
1834 </reference>
1835 <reference anchor="GNS" target="https://doi.org/10.1007/978-3-319-12280-9_9">
1836 <front>
1837 <title>A Censorship-Resistant, Privacy-Enhancing and Fully Decentralized Name System</title>
1838 <author initials="M." surname="Wachs" fullname="Matthias Wachs">
1839 <organization>Technische Universität München</organization>
1840 </author>
1841
1842 <author initials="M." surname="Schanzenbach" fullname="Martin Schanzenbach">
1843 <organization>Technische Universität München</organization>
1844 </author>
1845
1846 <author initials="C." surname="Grothoff"
1847 fullname="Christian Grothoff">
1848 <organization>Technische Universität München</organization>
1849 </author>
1850 <date year="2014"/>
1851 </front>
1852 </reference>
1853 <reference anchor="R5N" target="https://doi.org/10.1109/ICNSS.2011.6060022">
1854 <front>
1855 <title>R5N: Randomized recursive routing for restricted-route networks</title>
1856 <author initials="N. S." surname="Evans" fullname="Nathan S. Evans">
1857 <organization>Technische Universität München</organization>
1858 </author>
1859
1860 <author initials="C." surname="Grothoff"
1861 fullname="Christian Grothoff">
1862 <organization>Technische Universität München</organization>
1863 </author>
1864 <date year="2011"/>
1865 </front>
1866 </reference>
1867
1868
1869 <reference anchor="Argon2" target="https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/">
1870 <front>
1871 <title>The memory-hard Argon2 password hash and proof-of-work function</title>
1872 <author initials="A." surname="Biryukov" fullname="Alex Biryukov">
1873 <organization>University of Luxembourg</organization>
1874 </author>
1875
1876 <author initials="D." surname="Dinu" fullname="Daniel Dinu">
1877 <organization>University of Luxembourg</organization>
1878 </author>
1879
1880 <author initials="D." surname="Khovratovich"
1881 fullname="Dmitry Khovratovich">
1882 <organization>ABDK Consulting</organization>
1883 </author>
1884 <author initials="S." surname="Josefsson"
1885 fullname="Simon Josefsson">
1886 <organization>SJD AB</organization>
1887 </author>
1888 <date year="2020" month="March"/>
1889 <abstract>
1890 <t>
1891 This document describes the Argon2 memory-hard function for
1892 password hashing and proof-of-work applications. We provide an
1893 implementer-oriented description with
1894 test vectors. The purpose is to simplify adoption of Argon2 for
1895 Internet protocols. This document is a product of the Crypto Forum Research Group (CFRG)
1896 in the IRTF.
1897 </t>
1898 </abstract>
1899 </front>
1900 </reference>
1901 <!-- <reference anchor="ISO20022">
1902 <front>
1903 <title>ISO 20022 Financial Services - Universal financial industry message scheme</title>
1904 <author>
1905 <organization>International Organization for Standardization</organization>
1906 <address>
1907 <uri>http://www.iso.ch</uri>
1908 </address>
1909 </author>
1910 <date month="May" year="2013"/>
1911 </front>
1912 </reference>-->
1913 </references>
1914 <!-- Change Log
1915 v00 2017-07-23 MS Initial version
1916 -->
1917 </back>
1918 </rfc>
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index a4fa4ed..b7597ac 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -24,13 +24,13 @@
24<?rfc sortrefs="yes" ?> 24<?rfc sortrefs="yes" ?>
25<?rfc compact="yes" ?> 25<?rfc compact="yes" ?>
26<?rfc subcompact="no" ?> 26<?rfc subcompact="no" ?>
27<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-schanzen-gns-00" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3"> 27<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-schanzen-gns-01" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
28 <!-- xml2rfc v2v3 conversion 2.26.0 --> 28 <!-- xml2rfc v2v3 conversion 2.26.0 -->
29 <front> 29 <front>
30 <title abbrev="The GNU Name System"> 30 <title abbrev="The GNU Name System">
31 The GNU Name System 31 The GNU Name System
32 </title> 32 </title>
33 <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-00"/> 33 <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-01"/>
34 <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach"> 34 <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach">
35 <organization>GNUnet e.V.</organization> 35 <organization>GNUnet e.V.</organization>
36 <address> 36 <address>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-01 00:13:25 +0000