aboutsummaryrefslogtreecommitdiff
path: root/draft-schanzen-gns-00.xml
diff options
context:
space:
mode:
Diffstat (limited to 'draft-schanzen-gns-00.xml')
-rw-r--r--draft-schanzen-gns-00.xml1815
1 files changed, 1815 insertions, 0 deletions
diff --git a/draft-schanzen-gns-00.xml b/draft-schanzen-gns-00.xml
new file mode 100644
index 0000000..fad478c
--- /dev/null
+++ b/draft-schanzen-gns-00.xml
@@ -0,0 +1,1815 @@
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-00" 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-00"/>
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.
168 The public key is used to uniquely identify a GNS zone and is referred to
169 as the "zone key".
170 </dd>
171 </dl>
172 </section>
173 <section anchor="rrecords" numbered="true" toc="default">
174 <name>Resource Records</name>
175 <t>
176 A GNS implementor MUST provide a mechanism to create and manage resource
177 records for local zones. A local zone is established by creating a zone
178 key pair. Records may be added to each zone, hence a (local) persistency
179 mechanism for resource records and zones must be provided.
180 This local zone database is used by the GNS resolver implementation
181 and to publish record information.
182 </t>
183 <t>
184 A GNS resource record holds the data of a specific record in a zone.
185 The resource record format is defined as follows:
186 </t>
187 <figure anchor="figure_gnsrecord">
188 <artwork name="" type="" align="left" alt=""><![CDATA[
1890 8 16 24 32 40 48 56
190+-----+-----+-----+-----+-----+-----+-----+-----+
191| EXPIRATION |
192+-----+-----+-----+-----+-----+-----+-----+-----+
193| DATA SIZE | TYPE |
194+-----+-----+-----+-----+-----+-----+-----+-----+
195| FLAGS | DATA /
196+-----+-----+-----+-----+ /
197/ /
198/ /
199 ]]></artwork>
200 <!-- <postamble>which is a very simple example.</postamble>-->
201 </figure>
202 <t>where:</t>
203 <dl>
204 <dt>EXPIRATION</dt>
205 <dd>
206 denotes the absolute 64-bit expiration date of the record.
207 In microseconds since midnight (0 hour), January 1, 1970 in network
208 byte order.
209 </dd>
210 <dt>DATA SIZE</dt>
211 <dd>
212 denotes the 32-bit size of the DATA field in bytes and in network byte
213 order.
214 </dd>
215 <dt>TYPE</dt>
216 <dd>
217 is the 32-bit resource record type. This type can be one of the GNS resource
218 records as defined in <xref target="rrecords" /> or a DNS record
219 type as defined in <xref target="RFC1035" /> or any of the
220 complementary standardized DNS resource record types. This value must be
221 stored in network byte order. Note that values
222 below 2^16 are reserved for allocation via IANA (<xref target="RFC6895" />).
223 </dd>
224 <dt>FLAGS</dt>
225 <dd>
226 is a 32-bit resource record flags field (see below).
227 </dd>
228 <dt>DATA</dt>
229 <dd>
230 the variable-length resource record data payload. The contents are defined
231 by the
232 respective type of the resource record.
233 </dd>
234 </dl>
235 <t>
236 Flags indicate metadata surrounding the resource record. A flag
237 value of 0 indicates that all flags are unset. The following
238 illustrates the flag distribution in the 32-bit flag value of a
239 resource record:</t>
240 <figure anchor="figure_flag">
241 <artwork name="" type="" align="left" alt=""><![CDATA[
242... 5 4 3 2 1 0
243------+--------+--------+--------+--------+--------+
244/ ... | SHADOW | EXPREL | SUPPL | PRIVATE| / |
245------+--------+--------+--------+--------+--------+
246 ]]></artwork>
247 <!-- <postamble>which is a very simple example.</postamble>-->
248 </figure>
249 <t>
250 where:
251 </t>
252 <dl>
253 <dt>SHADOW</dt>
254 <dd>
255 If this flag is set, this record should be ignored by resolvers unless all (other)
256 records of the same record type have expired. Used to allow zone publishers to
257 facilitate good performance when records change by allowing them to put future
258 values of records into the DHT. This way, future values can propagate and may be
259 cached before the transition becomes active.
260 </dd>
261 <dt>EXPREL</dt>
262 <dd>
263 The expiration time value of the record is a relative time (still in microseconds)
264 and not an absolute time. This flag should never be encountered by a resolver
265 for records obtained from the DHT, but might be present when a resolver looks up
266 private records of a zone hosted locally.
267 </dd>
268 <dt>
269 SUPPL
270 </dt>
271 <dd>
272 This is a supplemental record. It is provided in addition to the
273 other records. This flag indicates that this record is not explicitly
274 managed alongside the other records under the respective name but
275 may be useful for the application. This flag should only be encountered
276 by a resolver for records obtained from the DHT.
277 </dd>
278 <dt>PRIVATE</dt>
279 <dd>
280 This is a private record of this peer and it should thus not be
281 published in the DHT. Thus, this flag should never be encountered by
282 a resolver for records obtained from the DHT.
283 Private records should still be considered just like
284 regular records when resolving labels in local zones.
285 </dd>
286 </dl>
287 <section anchor="gnsrecords_numbers" numbered="true" toc="default">
288 <name>Record Types</name>
289 <t>
290 A registry of GNS Record Types is described in Section 10. The
291 registration policy for this registry is "First Come First Served", as
292 described in <xref target="RFC8126"/>. When requesting new entries, careful
293 consideration of the following criteria is strongly advised:
294 FIXME: ausdenken was wir da gerne haetten.
295 </t>
296 </section>
297 <section anchor="gnsrecords_pkey" numbered="true" toc="default">
298 <name>PKEY</name>
299 <t>In GNS, a delegation of a label to a zone is represented through a PKEY
300 record. A PKEY resource record contains the public key of the zone to
301 delegate to. A PKEY record MUST be the only record under a label. No other
302 records are allowed. A PKEY DATA entry has the following format:</t>
303 <figure anchor="figure_pkeyrecord">
304 <artwork name="" type="" align="left" alt=""><![CDATA[
3050 8 16 24 32 40 48 56
306+-----+-----+-----+-----+-----+-----+-----+-----+
307| PUBLIC KEY |
308| |
309| |
310| |
311+-----+-----+-----+-----+-----+-----+-----+-----+
312 ]]></artwork>
313 <!-- <postamble>which is a very simple example.</postamble>-->
314 </figure>
315 <t>
316 where:
317 </t>
318 <dl>
319 <dt>PUBLIC KEY</dt>
320 <dd>
321 A 256-bit ECDSA zone key.
322 </dd>
323 </dl>
324 </section>
325 <section anchor="gnsrecords_gns2dns" numbered="true" toc="default">
326 <name>GNS2DNS</name>
327 <t>It is possible to delegate a label back into DNS through a GNS2DNS record.
328 The resource record contains a DNS name for the resolver to continue with
329 in DNS followed by a DNS server. Both names are in the format defined in
330 <xref target="RFC1034" /> for DNS names.
331 A GNS2DNS DATA entry has the following format:</t>
332 <figure anchor="figure_gns2dnsrecord">
333 <artwork name="" type="" align="left" alt=""><![CDATA[
3340 8 16 24 32 40 48 56
335+-----+-----+-----+-----+-----+-----+-----+-----+
336| DNS NAME |
337/ /
338/ /
339| |
340+-----+-----+-----+-----+-----+-----+-----+-----+
341| DNS SERVER NAME |
342/ /
343/ /
344| |
345+-----------------------------------------------+
346 ]]></artwork>
347 <!-- <postamble>which is a very simple example.</postamble>-->
348 </figure>
349 <t>
350 where:
351 </t>
352 <dl>
353 <dt>DNS NAME</dt>
354 <dd>
355 The name to continue with in DNS (0-terminated).
356 </dd>
357 <dt>DNS SERVER NAME</dt>
358 <dd>
359 The DNS server to use. May be an IPv4/IPv6 address in dotted decimal
360 form or a DNS name. It may also be a relative GNS name ending with a
361 "+" top-level domain. The value is UTF-8 encoded (also for DNS names)
362 and 0-terminated.
363 </dd>
364 </dl>
365 </section>
366
367 <section anchor="gnsrecords_leho" numbered="true" toc="default">
368 <name>LEHO</name>
369 <t>Legacy hostname records can be used by applications that are expected
370 to supply a DNS name on the application layer. The most common use case
371 is HTTP virtual hosting, which as-is would not work with GNS names as
372 those may not be globally unique.
373
374 A LEHO resource record is expected to be found together in a single
375 resource record with an IPv4 or IPv6 address.
376 A LEHO DATA entry has the following format:</t>
377 <figure anchor="figure_lehorecord">
378 <artwork name="" type="" align="left" alt=""><![CDATA[
3790 8 16 24 32 40 48 56
380+-----+-----+-----+-----+-----+-----+-----+-----+
381| LEGACY HOSTNAME |
382/ /
383/ /
384| |
385+-----+-----+-----+-----+-----+-----+-----+-----+
386 ]]></artwork>
387 <!-- <postamble>which is a very simple example.</postamble>-->
388 </figure>
389 <t>
390 where:
391 </t>
392 <dl>
393 <dt>LEGACY HOSTNAME</dt>
394 <dd>
395 A UTF-8 string (which is not 0-terminated) representing the legacy hostname.
396 </dd>
397 </dl>
398 <t>
399 NOTE: If an application uses a LEHO value in an HTTP request header
400 (e.g. "Host:" header) it must be converted to a punycode representation
401 <xref target="RFC5891" />.
402 </t>
403 </section>
404 <section anchor="gnsrecords_nick" numbered="true" toc="default">
405 <name>NICK</name>
406 <t>
407 Nickname records can be used by zone administrators to publish an
408 indication on what label this zone prefers to be referred to.
409 This is a suggestion to other zones what label to use when creating a
410 PKEY (<xref target="gnsrecords_pkey" />) record containing this zone's
411 public zone key.
412 This record SHOULD only be stored under the empty label "@" but MAY be
413 returned with record sets under any label as a supplemental record.
414 <xref target="nick_processing"/> details how a resolver must process
415 supplemental and non-supplemental NICK records.
416 A NICK DATA entry has the following format:
417 </t>
418 <figure anchor="figure_nickrecord">
419 <artwork name="" type="" align="left" alt=""><![CDATA[
4200 8 16 24 32 40 48 56
421+-----+-----+-----+-----+-----+-----+-----+-----+
422| NICKNAME |
423/ /
424/ /
425| |
426+-----+-----+-----+-----+-----+-----+-----+-----+
427 ]]></artwork>
428 <!-- <postamble>which is a very simple example.</postamble>-->
429 </figure>
430 <t>
431 where:
432 </t>
433 <dl>
434 <dt>NICKNAME</dt>
435 <dd>
436 A UTF-8 string (which is not 0-terminated) representing the preferred
437 label of the zone. This string MUST NOT include a "." character.
438 </dd>
439 </dl>
440 </section>
441 <section anchor="gnsrecords_box" numbered="true" toc="default">
442 <name>BOX</name>
443 <t>
444 In GNS, every "." in a name delegates to another zone, and
445 GNS lookups are expected to return all of the required useful
446 information in one record set. This is incompatible with the
447 special labels used by DNS for SRV and TLSA records. Thus, GNS
448 defines the BOX record format to box up SRV and TLSA records and
449 include them in the record set of the label they are associated
450 with. For example, a
451 TLSA record for "_https._tcp.foo.gnu" will be stored in the record set of
452 "foo.gnu" as a BOX record with service (SVC) 443 (https) and protocol (PROTO) 6
453 (tcp) and record TYPE "TLSA".
454 For reference, see also <xref target="RFC2782" />.
455 A BOX DATA entry has the following format:
456 </t>
457 <figure anchor="figure_boxrecord">
458 <artwork name="" type="" align="left" alt=""><![CDATA[
4590 8 16 24 32 40 48 56
460+-----+-----+-----+-----+-----+-----+-----+-----+
461| PROTO | SVC | TYPE |
462+-----------+-----------------------------------+
463| RECORD DATA |
464/ /
465/ /
466| |
467+-----+-----+-----+-----+-----+-----+-----+-----+
468 ]]></artwork>
469 <!-- <postamble>which is a very simple example.</postamble>-->
470 </figure>
471 <t>
472 where:
473 </t>
474 <dl>
475 <dt>PROTO</dt>
476 <dd>
477 the 16-bit protocol number, e.g. 6 for tcp. In network byte order.
478 </dd>
479 <dt>SVC</dt>
480 <dd>
481 the 16-bit service value of the boxed record, i.e. the port number.
482 In network byte order.
483 </dd>
484 <dt>TYPE</dt>
485 <dd>
486 is the 32-bit record type of the boxed record. In network byte order.
487 </dd>
488 <dt>RECORD DATA</dt>
489 <dd>
490 is a variable length field containing the "DATA" format of TYPE as
491 defined for the respective TYPE in DNS.
492 </dd>
493 </dl>
494 </section>
495 <section anchor="gnsrecords_vpn" numbered="true" toc="default">
496 <name>VPN</name>
497 <t>
498 A VPN DATA entry has the following format:</t>
499 <figure anchor="figure_vpnrecord">
500 <artwork name="" type="" align="left" alt=""><![CDATA[
5010 8 16 24 32 40 48 56
502+-----+-----+-----+-----+-----+-----+-----+-----+
503| HOSTING PEER PUBLIC KEY |
504| (256 bits) |
505| |
506| |
507+-----------+-----------------------------------+
508| PROTO | SERVICE NAME |
509+-----------+ +
510/ /
511/ /
512| |
513+-----+-----+-----+-----+-----+-----+-----+-----+
514 ]]></artwork>
515 <!-- <postamble>which is a very simple example.</postamble>-->
516 </figure>
517 <t>
518 where:
519 </t>
520 <dl>
521 <dt>HOSTING PEER PUBLIC KEY</dt>
522 <dd>
523 is a 256-bit EdDSA public key identifying the peer hosting the
524 service.
525 </dd>
526 <dt>PROTO</dt>
527 <dd>
528 the 16-bit protocol number, e.g. 6 for TCP. In network byte order.
529 </dd>
530 <dt>SERVICE NAME</dt>
531 <dd>
532 a shared secret used to identify the service at the hosting peer,
533 used to derive the port number requird to connect to the service.
534 The service name MUST be a 0-terminated UTF-8 string.
535 </dd>
536 </dl>
537 </section>
538 </section>
539
540 <section anchor="publish" numbered="true" toc="default">
541 <name>Publishing Records</name>
542 <t>
543 GNS resource records are published in a distributed hash table (DHT).
544 We assume that a DHT provides two functions: GET(key) and PUT(key,value).
545 In GNS, resource records are grouped by their respective labels,
546 encrypted and published together in a single resource records block
547 (RRBLOCK) in the DHT under a key "q": PUT(q, RRBLOCK).
548 The key "q" which is derived from the zone key "zk" and the respective
549 label of the contained records.
550 </t>
551 <section anchor="blinding" numbered="true" toc="default">
552 <name>Key Derivations</name>
553 <t>
554 Given a label, the DHT key "q" is derived as follows:
555 </t>
556 <artwork name="" type="" align="left" alt=""><![CDATA[
557PRK_h := HKDF-Extract ("key-derivation", zk)
558h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
559d_h := h * d mod L
560zk_h := h mod L * zk
561q := SHA512 (zk_h)
562 ]]></artwork>
563 <t>
564 We use a hash-based key derivation function (HKDF) as defined in
565 <xref target="RFC5869" />. We use HMAC-SHA512 for the extraction
566 phase and HMAC-SHA256 for the expansion phase.
567 </t>
568 <dl>
569 <dt>PRK_h</dt>
570 <dd>
571 is key material retrieved using an HKDF using the string
572 "key-derivation" as salt and the public zone key "zk" as initial
573 keying material.
574 </dd>
575 <dt>h</dt>
576 <dd>
577 is the 512-bit HKDF expansion result. The expansion info input is a
578 concatenation of the label and string "gns".
579 </dd>
580 <dt>d</dt>
581 <dd>
582 is the 256-bit private zone key as defined in <xref target="zones" />.
583 </dd>
584 <dt>label</dt>
585 <dd>
586 is a UTF-8 string under which the resource records are published.
587 </dd>
588 <dt>d_h</dt>
589 <dd>
590 is a 256-bit private key derived from the "d" using the
591 keying material "h".
592 </dd>
593 <dt>zk_h</dt>
594 <dd>
595 is a 256-bit public key derived from the zone key "zk" using the
596 keying material "h".
597 </dd>
598 <dt>L</dt>
599 <dd>
600 is the prime-order subgroup as defined in <xref target="zones" />.
601 </dd>
602 <dt>q</dt>
603 <dd>
604 Is the 512-bit DHT key under which the resource records block is
605 published.
606 It is the SHA512 hash over the public key "zk_h" corresponding to the
607 derived private key "d_h".
608 </dd>
609 </dl>
610 <t>
611 We point out that the multiplication of "zk" with "h" is a point multiplication,
612 while the multiplication of "d" with "h" is a scalar multiplication.
613 </t>
614 </section>
615 <section anchor="wire" numbered="true" toc="default">
616 <name>Resource Records Block</name>
617 <t>
618 GNS records are grouped by their labels and published as a single
619 block in the DHT. The grouped record sets MAY be paired with any
620 number of supplemental records. Supplemental records must have the
621 supplemental flag set (See <xref target="rrecords"/>).
622 The contained resource records are encrypted using a symmetric
623 encryption scheme.
624 A GNS implementation must publish RRBLOCKs
625 in accordance to the properties and recommendations of the underlying
626 DHT. This may include a periodic refresh publication.
627 A GNS RRBLOCK has the following format:
628 </t>
629 <figure anchor="figure_record_block">
630 <artwork name="" type="" align="left" alt=""><![CDATA[
6310 8 16 24 32 40 48 56
632+-----+-----+-----+-----+-----+-----+-----+-----+
633| SIGNATURE |
634| |
635| |
636| |
637| |
638| |
639| |
640| |
641+-----+-----+-----+-----+-----+-----+-----+-----+
642| PUBLIC KEY |
643| |
644| |
645| |
646+-----+-----+-----+-----+-----+-----+-----+-----+
647| SIZE | PURPOSE |
648+-----+-----+-----+-----+-----+-----+-----+-----+
649| EXPIRATION |
650+-----+-----+-----+-----+-----+-----+-----+-----+
651| BDATA /
652/ /
653/ |
654+-----+-----+-----+-----+-----+-----+-----+-----+
655 ]]></artwork>
656 </figure>
657 <t>where:</t>
658 <dl>
659 <dt>SIGNATURE</dt>
660 <dd>
661 A 512-bit ECDSA deterministic signature compliant with
662 <xref target="RFC6979" />. The signature is computed over the data
663 following the PUBLIC KEY field.
664 The signature is created using the derived private key "d_h" (see
665 <xref target="publish" />).
666 </dd>
667 <dt>PUBLIC KEY</dt>
668 <dd>
669 is the 256-bit public key "zk_h" to be used to verify SIGNATURE. The
670 wire format of this value is defined in <xref target="RFC8032" />,
671 Section 5.1.5.
672 </dd>
673 <dt>SIZE</dt>
674 <dd>
675 A 32-bit value containing the length of the signed data following the
676 PUBLIC KEY field in network byte order. This value always includes the
677 length of the fields SIZE (4), PURPOSE (4) and EXPIRATION (8) in
678 addition to the length of the BDATA. While a 32-bit value is used,
679 implementations MAY refuse to publish blocks beyond a certain
680 size significantly below 4 GB. However, a minimum block size of
681 62 kilobytes MUST be supported.
682 <!-- See GNUNET_CONSTANTS_MAX_BLOCK_SIZE -->
683 </dd>
684 <dt>PURPOSE</dt>
685 <dd>
686 A 32-bit signature purpose flag. This field MUST be 15 (in network
687 byte order).
688 </dd>
689 <dt>EXPIRATION</dt>
690 <dd>
691 Specifies when the RRBLOCK expires and the encrypted block
692 SHOULD be removed from the DHT and caches as it is likely stale.
693 However, applications MAY continue to use non-expired individual
694 records until they expire. The value MUST be set to the
695 expiration time of the resource record contained within this block with the
696 smallest expiration time.
697 If a records block includes shadow records, then the maximum
698 expiration time of all shadow records with matching type and the
699 expiration times of the non-shadow records is considered.
700 This is a 64-bit absolute date in microseconds since midnight
701 (0 hour), January 1, 1970 in network byte order.
702 </dd>
703 <dt>BDATA</dt>
704 <dd>
705 The encrypted resource records with a total size of SIZE - 16.
706 </dd>
707 </dl>
708 </section>
709 <section anchor="recordencryption" numbered="true" toc="default">
710 <name>Record Data Encryption and Decryption</name>
711 <t>
712 A symmetric encryption scheme is used to encrypt the resource records
713 set RDATA into the BDATA field of a GNS RRBLOCK.
714 The wire format of the RDATA looks as follows:
715 </t>
716 <figure anchor="figure_rdata">
717 <artwork name="" type="" align="left" alt=""><![CDATA[
7180 8 16 24 32 40 48 56
719+-----+-----+-----+-----+-----+-----+-----+-----+
720| RR COUNT | EXPIRA- /
721+-----+-----+-----+-----+-----+-----+-----+-----+
722/ -TION | DATA SIZE |
723+-----+-----+-----+-----+-----+-----+-----+-----+
724| TYPE | FLAGS |
725+-----+-----+-----+-----+-----+-----+-----+-----+
726| DATA /
727/ /
728/ |
729+-----+-----+-----+-----+-----+-----+-----+-----+
730| EXPIRATION |
731+-----+-----+-----+-----+-----+-----+-----+-----+
732| DATA SIZE | TYPE |
733+-----+-----+-----+-----+-----+-----+-----+-----+
734| FLAGS | DATA /
735+-----+-----+-----+-----+ /
736/ +-----------------------/
737/ | /
738+-----------------------+ /
739/ PADDING /
740/ /
741 ]]></artwork>
742 <!-- <postamble>which is a very simple example.</postamble>-->
743 </figure>
744 <t>where:</t>
745 <dl>
746 <dt>RR COUNT</dt>
747 <dd>
748 A 32-bit value containing the number of variable-length resource
749 records which are
750 following after this field in network byte order.
751 </dd>
752 <dt>EXPIRATION, DATA SIZE, TYPE, FLAGS and DATA</dt>
753 <dd>
754 These fields were defined
755 in the resource record format in <xref target="rrecords" />.
756 There MUST be a total of RR COUNT of these resource records
757 present.
758 </dd>
759 <dt>PADDING</dt>
760 <dd>
761 The padding MUST contain the value 0 in all octets.
762 The padding MUST ensure that the size of the RDATA WITHOUT the RR
763 COUNT field is a power of two.
764 As a special exception, record sets with (only) a PKEY record type
765 are never padded. Note that a record set with a PKEY record MUST NOT
766 contain other records.
767 </dd>
768
769 </dl>
770 <t>
771 The symmetric keys and initialization vectors are derived from the
772 record label and the zone key "zk". For decryption of the resource
773 records block payload, the key material "K" and initialization vector
774 "IV" for the symmetric cipher are derived as follows:
775 </t>
776 <!-- OLD VERSION
777 PRK_kiv := HKDF-Extract (zk, label)
778 K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
779 IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
780 -->
781 <artwork name="" type="" align="left" alt=""><![CDATA[
782PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
783PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
784K := HKDF-Expand (PRK_k, label, 512 / 8);
785IV := HKDF-Expand (PRK_iv, label, 256 / 8)
786 ]]></artwork>
787 <t>
788 HKDF is a hash-based key derivation function as defined in
789 <xref target="RFC5869" />. Specifically, HMAC-SHA512 is used for the
790 extraction phase and HMAC-SHA256 for the expansion phase.
791 The output keying material is 64 octets (512 bit) for the symmetric
792 keys and 32 octets (256 bit) for the initialization vectors.
793 We divide the resulting keying material "K" into a 256-bit AES
794 <xref target="RFC3826" /> key
795 and a 256-bit TWOFISH <xref target="TWOFISH" /> key:
796 </t>
797 <figure anchor="figure_hkdf_keys">
798 <artwork name="" type="" align="left" alt=""><![CDATA[
7990 8 16 24 32 40 48 56
800+-----+-----+-----+-----+-----+-----+-----+-----+
801| AES KEY |
802| |
803| |
804| |
805+-----+-----+-----+-----+-----+-----+-----+-----+
806| TWOFISH KEY |
807| |
808| |
809| |
810+-----+-----+-----+-----+-----+-----+-----+-----+
811 ]]></artwork>
812 <!-- <postamble>which is a very simple example.</postamble>-->
813 </figure>
814 <t>
815 Similarly, we divide "IV" into a 128-bit initialization vector
816 and a 128-bit initialization vector:
817 </t>
818 <figure anchor="figure_hkdf_ivs">
819 <artwork name="" type="" align="left" alt=""><![CDATA[
8200 8 16 24 32 40 48 56
821+-----+-----+-----+-----+-----+-----+-----+-----+
822| AES IV |
823| |
824+-----+-----+-----+-----+-----+-----+-----+-----+
825| TWOFISH IV |
826| |
827+-----+-----+-----+-----+-----+-----+-----+-----+
828 ]]></artwork>
829 <!-- <postamble>which is a very simple example.</postamble>-->
830 </figure>
831
832 <t>
833 The keys and IVs are used for a CFB128-AES-256 and
834 CFB128-TWOFISH-256 chained symmetric cipher. Both ciphers are used in
835 Cipher FeedBack (CFB) mode <xref target="RFC3826" />.
836 </t>
837 <artwork name="" type="" align="left" alt=""><![CDATA[
838RDATA := AES(K[0:31], IV[0:15],
839 TWOFISH(K[32:63], IV[16:31], BDATA))
840BDATA := TWOFISH(K[32:63], IV[16:31],
841 AES(K[0:31], IV[0:15], RDATA))
842 ]]></artwork>
843 </section>
844 </section>
845 <section anchor="encoding" numbered="true" toc="default">
846 <name>Internationalization and Character Encoding</name>
847 <t>
848 All labels in GNS are encoded in UTF-8 <xref target="RFC3629" />.
849 This does not include any DNS names found in DNS records, such as CNAME
850 records, which are internationalized through the IDNA specifications
851 <xref target="RFC5890" />.
852 </t>
853 </section>
854 <section anchor="resolution" numbered="true" toc="default">
855 <name>Name Resolution</name>
856 <t>
857 Names in GNS are resolved by recursively querying the DHT record storage.
858 In the following, we define how resolution is initiated and each
859 iteration in the resolution is processed.
860 </t>
861 <t>
862 GNS resolution of a name must start in a given starting zone indicated using
863 a zone public key.
864 Details on how the starting zone may be determined is discussed in
865 <xref target="governance" />.
866 </t>
867 <t>
868 When GNS name resolution is requested, a desired record type MAY be
869 provided by the client.
870 The GNS resolver will use the desired record type to guide
871 processing, for example by providing conversion of VPN records to A
872 or AAAA records, if that is desired.
873
874 However, filtering of record sets according to the required record
875 types MUST still be done by the client after the resource record set
876 is retrieved.
877 </t>
878 <section anchor="recursion" numbered="true" toc="default">
879 <name>Recursion</name>
880 <t>
881 In each step of the recursive name resolution, there is an
882 authoritative zone zk and a name to resolve. The name may be empty.
883 Initially, the authoritative zone is the start zone. If the name
884 is empty, it is interpreted as the apex label "@".
885 </t>
886 <t>
887 From here, the following steps are recursively executed, in order:
888 </t>
889 <ol>
890 <li>Extract the right-most label from the name to look up.</li>
891 <li>Calculate q using the label and zk as defined in
892 <xref target="blinding" />.</li>
893 <li>Perform a DHT query GET(q) to retrieve the RRBLOCK.</li>
894 <li>Verify and process the RRBLOCK and decrypt the BDATA contained
895 in it as defined in <xref target="recordencryption" />.</li>
896 </ol>
897 <t>
898 Upon receiving the RRBLOCK from the DHT, apart from verifying the
899 provided signature, the resolver MUST check that the authoritative
900 zone key was used to sign the record:
901 The derived zone key "h*zk" MUST match the public key provided in
902 the RRBLOCK, otherwise the RRBLOCK MUST be ignored and the DHT lookup
903 GET(q) MUST continue.
904 </t>
905 </section>
906 <section anchor="record_processing" numbered="true" toc="default">
907 <name>Record Processing</name>
908 <t>
909 Record processing occurs at the end of a single recursion. We assume
910 that the RRBLOCK has been cryptographically verified and decrypted.
911 At this point, we must first determine if we have received a valid
912 record set in the context of the name we are trying to resolve:
913 </t>
914 <ol>
915 <li>
916 Case 1:
917 If the remainder of the name to resolve is empty and the record set
918 does not consist of a PKEY, CNAME or DNS2GNS record, the record set
919 is the result and the recursion is concluded.
920 </li>
921 <li>
922 Case 2:
923 If the name to be resolved is of the format
924 "_SERVICE._PROTO" and the record set contains one or more matching BOX
925 records, the records in the BOX records are the result and the recusion
926 is concluded (<xref target="box_processing" />).
927 </li>
928 <li>
929 Case 3:
930 If the remainder of the name to resolve is not empty and
931 does not match the "_SERVICE._PROTO" syntax, then the current record set
932 MUST consist of a single PKEY record (<xref target="pkey_processing" />),
933 a single CNAME record (<xref target="cname_processing" />),
934 or one or more GNS2DNS records (<xref target="gns2dns_processing" />),
935 which are processed as described in the respective sections below.
936 The record set may include any number of supplemental records.
937 Otherwise, resolution fails
938 and the resolver MUST return an empty record set.
939
940 Finally, after the recursion terminates, the client preferences
941 for the record type SHOULD be considered. If a VPN record is found
942 and the client requests an A or AAAA record, the VPN record
943 SHOULD be converted (<xref target="vpn_processing" />)
944 if possible.
945 </li>
946 </ol>
947 <section anchor="pkey_processing" numbered="true" toc="default">
948 <name>PKEY</name>
949 <t>
950 When the resolver encounters a PKEY record and the remainder of
951 the name is not empty, resolution continues
952 recursively with the remainder of the name in the
953 GNS zone specified in the PKEY record.
954 </t>
955 <t>
956 If the remainder of the name to resolve is empty and we have
957 received a record set containing only a single PKEY record, the
958 recursion is continued with the PKEY as authoritative zone and
959 the empty apex label "@" as remaining name, except in the case
960 where the desired record type is PKEY, in which case the PKEY
961 record is returned and the resolution is concluded without
962 resolving the empty apex label.
963 </t>
964 </section>
965 <section anchor="gns2dns_processing" numbered="true" toc="default">
966 <name>GNS2DNS</name>
967 <t>
968 When a resolver encounters one or more GNS2DNS records and the remaining name
969 is empty and the desired record type is GNS2DNS, the GNS2DNS
970 records are returned.
971 </t>
972 <t>
973 Otherwise, it is expected that the resolver first resolves the
974 IP(s) of the specified DNS name server(s). GNS2DNS records MAY
975 contain numeric IPv4 or IPv6 addresses, allowing the resolver to
976 skip this step.
977 The DNS server names may themselves be names in GNS or DNS.
978 If the DNS server name ends in ".+", the rest of the name is to be
979 interpreted relative to the zone of the GNS2DNS record.
980 If the DNS server name ends in ".&lt;Base32(zk)&gt;", the DNS
981 server name is to be resolved against the GNS zone zk.
982 </t>
983 <t>
984 Multiple GNS2DNS records may be stored under the same label,
985 in which case the resolver MUST try all of them.
986 The resolver MAY try them in any order or even in parallel.
987 If multiple GNS2DNS records are present, the DNS name MUST be
988 identical for all of them, if not the resolution fails and an
989 emtpy record set is returned as the record set is invalid.
990 </t>
991 <t>
992 Once the IP addresses of the DNS servers have been determined,
993 the DNS name from the GNS2DNS record is appended
994 to the remainder of the name to be resolved, and
995 resolved by querying the DNS name server(s). As the DNS servers
996 specified are possibly authoritative DNS servers, the GNS resolver MUST
997 support recursive resolution and MUST NOT delegate this to the
998 authoritative DNS servers.
999 The first successful recursive name resolution result
1000 is returned to the client.
1001 In addition, the resolver returns the queried DNS name as a
1002 supplemental LEHO record (<xref target="gnsrecords_leho" />) with a
1003 relative expiration time of one hour.
1004 </t>
1005 <t>
1006 GNS resolvers SHOULD offer a configuration
1007 option to disable DNS processing to avoid information leakage
1008 and provide a consistent security profile for all name resolutions.
1009 Such resolvers would return an empty record set upon encountering
1010 a GNS2DNS record during the recursion. However, if GNS2DNS records
1011 are encountered in the record set for the apex and a GNS2DNS record
1012 is expicitly requested by the application, such records MUST
1013 still be returned, even if DNS support is disabled by the
1014 GNS resolver configuration.
1015 </t>
1016 </section>
1017 <section anchor="cname_processing" numbered="true" toc="default">
1018 <name>CNAME</name>
1019 <t>
1020 If a CNAME record is encountered, the canonical name is
1021 appended to the remaining name, except if the remaining name
1022 is empty and the desired record type is CNAME, in which case
1023 the resolution concludes with the CNAME record.
1024 If the canonical name ends in ".+",
1025 resolution continues in GNS with the new name in the
1026 current zone. Otherwise, the resulting name is resolved via the
1027 default operating system name resolution process.
1028 This may in turn again trigger a GNS resolution process depending
1029 on the system configuration.
1030 <!-- Note: this permits non-DNS resolvers to be triggered via NSS! -->
1031 </t>
1032 <t>
1033 The recursive DNS resolution process may yield a CNAME as well
1034 which in turn may either point into the DNS or GNS namespace
1035 (if it ends in a ".&lt;Base32(zk)&gt;").
1036 In order to prevent infinite loops, the resolver MUST
1037 implement loop detections or limit the number of recursive
1038 resolution steps.
1039 If the last CNAME was a DNS name, the resolver returns the DNS name
1040 as a supplemental LEHO record (<xref target="gnsrecords_leho" />)
1041 with a relative expiration time of one hour.
1042 <!-- Note: Martin: do we actually implement this in GNS today?
1043 Seems rather tricky to detect if we go via NSS... -->
1044 </t>
1045 </section>
1046 <section anchor="box_processing" numbered="true" toc="default">
1047 <name>BOX</name>
1048 <t>
1049 When a BOX record is received, a GNS resolver must unbox it if the
1050 name to be resolved continues with "_SERVICE._PROTO".
1051 Otherwise, the BOX record is to be left untouched. This way, TLSA
1052 (and SRV) records do not require a separate network request, and
1053 TLSA records become inseparable from the corresponding address
1054 records.
1055 </t>
1056 </section>
1057 <section anchor="vpn_processing" numbered="true" toc="default">
1058 <name>VPN</name>
1059 <t>
1060 At the end of the recursion,
1061 if the queried record type is either A or AAAA and the retrieved
1062 record set contains at least one VPN record, the resolver SHOULD
1063 open a tunnel and return the IPv4 or IPv6 tunnel address,
1064 respectively.
1065 The type of tunnel depends on the contents of the VPN record data.
1066 The VPN record MUST be returned if the resolver implementation
1067 does not support setting up a tunnnel.
1068 </t>
1069 </section>
1070 <section anchor="nick_processing" numbered="true" toc="default">
1071 <name>NICK</name>
1072 <t>
1073 NIICK records are only relevant to the recursive resolver
1074 if the record set in question is the final result which is to
1075 be returned to the client. The encountered NICK records may either
1076 be supplemental (see <xref target="rrecords"/>) or
1077 non-supplemental.
1078 If the NICK record is supplemental, the resolver only returns the
1079 record set if one of the non-supplemental records matches the
1080 queried record type.
1081 </t>
1082 <t>
1083 The differentiation between a supplemental and non-supplemental
1084 NICK record allows the client to match the record to the
1085 authoritative zone. Consider the following example:
1086 </t>
1087 <figure>
1088 <artwork name="" type="" align="left" alt=""><![CDATA[
1089Query: alice.doe (type=A)
1090Result:
1091A: 1.2.3.4
1092NICK: eve
1093 ]]></artwork>
1094 </figure>
1095 <t>
1096 In this example, the returned NICK record is non-supplemental.
1097 For the client, this means that the NICK belongs to the zone
1098 "alice.doe" and is published under the empty label along with an A
1099 record. The NICK record should be interpreted as: The zone defined by
1100 "alice.doe" wants to be referred to as "eve".
1101 In contrast, consider the following:
1102 </t>
1103 <figure>
1104 <artwork name="" type="" align="left" alt=""><![CDATA[
1105Query: alice.doe (type=A)
1106Result:
1107A: 1.2.3.4
1108NICK: john (Supplemental)
1109 ]]></artwork>
1110 </figure>
1111 <t>
1112 In this case, the NICK record is marked as supplemental. This means that
1113 the NICK record belongs to the zone "doe" and is published under the
1114 label "alice" along with an A record. The NICK record should be
1115 interpreted as: The zone defined by "doe" wants to be referred to as
1116 "john". This distinction is likely useful for other records published as
1117 supplemental.
1118 </t>
1119
1120
1121 </section>
1122 </section>
1123 </section>
1124 <section anchor="revocation" numbered="true" toc="default">
1125 <name>Zone Revocation</name>
1126 <t>
1127 Whenever a recursive resolver encounters a new GNS zone, it MUST
1128 check against the local revocation list whether the respective
1129 zone key has been revoked. If the zone key was revoked, the
1130 resolution MUST fail with an empty result set.
1131 </t>
1132 <t>
1133 In order to revoke a zone key, a signed revocation object SHOULD be
1134 published.
1135 This object MUST be signed using the private zone key.
1136 The revocation object is flooded in the overlay network. To prevent
1137 flooding attacks, the revocation message MUST contain a proof of work
1138 (PoW).
1139 The revocation message including the PoW MAY be calculated
1140 ahead of time to support timely revocation.
1141 </t>
1142 <t>
1143 For all occurences below, "Argon2d" is the Password-based Key
1144 Derivation Function as defined in <xref target="Argon2" />. For the
1145 PoW calculations the algorithm is instantiated with the
1146 following parameters:
1147 </t>
1148 <artwork name="" type="" align="left" alt=""><![CDATA[
1149S := "gnunet-revocation-proof-of-work" /* Salt */
1150t := 3 /* Iterations */
1151m := 1024 /* Memory size, 1 MiB */
1152T := 64 /* Tag (=output) length in bytes */
1153p := 1 /* Parallelization parameter */
1154v := 0x13 /* Version */
1155y := 0 /* Type (Argon2d) */
1156X, K are unused
1157 ]]></artwork>
1158 <t>
1159 The following is the message string "P" on which the PoW is
1160 calculated:
1161 </t>
1162 <figure anchor="figure_revocation">
1163 <artwork name="" type="" align="left" alt=""><![CDATA[
11640 8 16 24 32 40 48 56
1165+-----+-----+-----+-----+-----+-----+-----+-----+
1166| POW |
1167+-----------------------------------------------+
1168| TIMESTAMP |
1169+-----------------------------------------------+
1170| PUBLIC KEY |
1171| |
1172| |
1173| |
1174+-----+-----+-----+-----+-----+-----+-----+-----+
1175 ]]></artwork>
1176 </figure>
1177 <t>where:</t>
1178 <dl>
1179 <dt>POW</dt>
1180 <dd>
1181 A 64-bit solution to the PoW. In network byte order.
1182 </dd>
1183 <dt>TIMESTAMP</dt>
1184 <dd>
1185 denotes the absolute 64-bit date when the revocation was computed.
1186 In microseconds since midnight (0 hour), January 1, 1970 in network
1187 byte order.
1188 </dd>
1189 <dt>PUBLIC KEY</dt>
1190 <dd>
1191 A 512-bit ECDSA deterministic signature compliant with
1192 <xref target="RFC6979" /> over the public zone zk of the zone
1193 which is revoked and corresponds to the key used in the PoW.
1194 The signature is created using the private zone key "d" (see
1195 <xref target="zones" />).
1196 </dd>
1197 </dl>
1198 <t>
1199 Traditionally, PoW schemes require to find a "POW" such that
1200 at least D leading zeroes are found in the hash result.
1201 D is then referred to as the "difficulty" of the PoW.
1202 In order to reduce the variance in time it takes to calculate the
1203 PoW, we require that a number "Z" different PoWs must be
1204 found that on average have "D" leading zeroes.
1205 </t>
1206 <t>
1207 The resulting proofs may then published and disseminated. The concrete
1208 dissemination and publication methods are out of scope of this
1209 document. Given an average difficulty of "D", the proofs have an
1210 expiration time of EPOCH. With each additional bit difficulty, the
1211 lifetime of the proof is prolonged for another EPOCH.
1212 Consequently, by calculating a more difficult PoW, the lifetime of the
1213 proof can be increased on demand by the zone owner.
1214 </t>
1215 <t>
1216 The parameters are defined as follows:
1217 </t>
1218 <dl>
1219 <dt>Z</dt>
1220 <dd>The number of PoWs required is fixed at 32.</dd>
1221 <dt>D</dt>
1222 <dd>The difficulty is fixed at 25.</dd>
1223 <dt>EPOCH</dt>
1224 <dd>A single epoch is fixed at 365 days.</dd>
1225 </dl>
1226 <t>
1227 Given that proof has been found, a revocation data object is defined
1228 as follows:
1229 </t>
1230 <figure anchor="figure_revocationdata">
1231 <artwork name="" type="" align="left" alt=""><![CDATA[
12320 8 16 24 32 40 48 56
1233+-----+-----+-----+-----+-----+-----+-----+-----+
1234| TIMESTAMP |
1235+-----+-----+-----+-----+-----+-----+-----+-----+
1236| TTL |
1237+-----+-----+-----+-----+-----+-----+-----+-----+
1238| POW_0 |
1239+-----+-----+-----+-----+-----+-----+-----+-----+
1240| ... |
1241+-----+-----+-----+-----+-----+-----+-----+-----+
1242| POW_Z-1 |
1243+-----------------------------------------------+
1244| SIGNATURE |
1245| |
1246| |
1247| |
1248| |
1249| |
1250| |
1251| |
1252+-----+-----+-----+-----+-----+-----+-----+-----+
1253| PUBLIC KEY |
1254| |
1255| |
1256| |
1257+-----+-----+-----+-----+-----+-----+-----+-----+
1258 ]]></artwork>
1259 </figure>
1260 <t>where:</t>
1261 <dl>
1262 <dt>TIMESTAMP</dt>
1263 <dd>
1264 denotes the absolute 64-bit date when the revocation was computed.
1265 In microseconds since midnight (0 hour), January 1, 1970 in network
1266 byte order. This is the same value as the timestamp used in the
1267 individual PoW calculations.
1268 </dd>
1269 <dt>TTL</dt>
1270 <dd>
1271 denotes the relative 64-bit time to live of of the record in
1272 microseconds also in network byte order. This field is informational
1273 for a verifier. The verifier may discard revocation if the TTL
1274 indicates that it is already expired. However, the actual TTL of the
1275 revocation must be determined by examining the leading zeros in the
1276 proof of work calculation.
1277 </dd>
1278 <dt>POW_i</dt>
1279 <dd>
1280 The values calculated as part of the PoW, in network byte order.
1281 Each POW_i MUST be unique in the set of POW values.
1282 To facilitate fast verification
1283 of uniqueness, the POW values must be given in strictly
1284 monotonically increasing order in the message.
1285 </dd>
1286 <dt>SIGNATURE</dt>
1287 <dd>
1288 A 512-bit ECDSA deterministic signature compliant with
1289 <xref target="RFC6979" /> over the public zone zk of the zone
1290 which is revoked and corresponds to the key used in the PoW.
1291 The signature is created using the private zone key "d" (see
1292 <xref target="zones" />).
1293 </dd>
1294 <dt>PUBLIC KEY</dt>
1295 <dd>
1296 is the 256-bit public key "zk" of the zone which is being revoked and
1297 the key to be used to verify SIGNATURE. The
1298 wire format of this value is defined in <xref target="RFC8032" />,
1299 Section 5.1.5.
1300 </dd>
1301 </dl>
1302 <t>
1303 The signature over the public key covers a 32 bit pseudo header
1304 conceptually prefixed to the public key. The pseudo header includes
1305 the key length and signature purpose:
1306 </t>
1307 <figure anchor="figure_revsigwithpseudo">
1308 <artwork name="" type="" align="left" alt=""><![CDATA[
13090 8 16 24 32 40 48 56
1310+-----+-----+-----+-----+-----+-----+-----+-----+
1311| SIZE (0x30) | PURPOSE (0x03) |
1312+-----+-----+-----+-----+-----+-----+-----+-----+
1313| PUBLIC KEY |
1314| |
1315| |
1316| |
1317+-----+-----+-----+-----+-----+-----+-----+-----+
1318| TIMESTAMP |
1319+-----+-----+-----+-----+-----+-----+-----+-----+
1320 ]]></artwork>
1321 </figure>
1322 <t>where:</t>
1323 <dl>
1324 <dt>SIZE</dt>
1325 <dd>
1326 A 32-bit value containing the length of the signed data in bytes
1327 (48 bytes) in network byte order.
1328 </dd>
1329 <dt>PURPOSE</dt>
1330 <dd>
1331 A 32-bit signature purpose flag. This field MUST be 3 (in network
1332 byte order).
1333 </dd>
1334 <dt>PUBLIC KEY / TIMESTAMP</dt>
1335 <dd>Both values as defined in the revocation data object above.</dd>
1336 </dl>
1337 <t>
1338 In order to verify a revocation the following steps must be taken,
1339 in order:
1340 </t>
1341 <ol>
1342 <li>The current time MUST be between TIMESTAMP and
1343 TIMESTAMP+TTL.</li>
1344 <li>The signature MUST match the public key.</li>
1345 <li>The set of POW values MUST NOT contain duplicates.</li>
1346 <li>The average number of leading zeroes resulting from the provided
1347 POW values D' MUST be greater than D.</li>
1348 <li>The validation period (TTL) of the revocation is calculated as
1349 (D'-D) * EPOCH * 1.1. The EPOCH is extended by
1350 10% in order to deal with unsynchronized clocks.
1351 The TTL added on top of the TIMESTAMP yields the
1352 expiration date.</li>
1353 </ol>
1354 </section>
1355 <section anchor="governance" numbered="true" toc="default">
1356 <name>Determining the Root Zone and Zone Governance</name>
1357 <t>
1358 The resolution of a GNS name must start in a given start zone
1359 indicated to the resolver using any public zone key.
1360 The local resolver may have a local start zone configured/hard-coded
1361 which points to a local or remote start zone key.
1362 A resolver client may also determine the start zone from the
1363 suffix of the name given for resolution or using information
1364 retrieved out of band.
1365 The governance model of any zone is at the sole discretion
1366 of the zone owner. However, the choice of start zone(s) is at the sole
1367 discretion of the local system administrator or user.
1368 </t>
1369 <t>
1370 This is an important distinguishing factor from the Domain Name System
1371 where root zone governance is centralized at the Internet Corporation
1372 for Assigned Names and Numbers (ICANN).
1373 In DNS terminology, GNS roughly follows the idea of a hyper-hyper
1374 local root zone deployment, with the difference that it is not
1375 expected that all deployments use the same local root zone.
1376 </t>
1377 <t>
1378 In the following, we give examples how a local client resolver SHOULD
1379 discover the start zone. The process given is not exhaustive and
1380 clients MAY suppliement it with other mechanisms or ignore it if the
1381 particular application requires a different process.
1382 </t>
1383 <t>
1384 GNS clients SHOULD first try to interpret the top-level domain of
1385 a GNS name as a zone key.
1386 For example. if the top-level domain is a Base32-encoded public zone
1387 key "zk", the root zone of the resolution process is implicitly given
1388 by the name:
1389 </t>
1390 <artwork name="" type="" align="left" alt=""><![CDATA[
1391Example name: www.example.<Base32(zk)>
1392=> Root zone: zk
1393=> Name to resolve from root zone: www.example
1394 ]]></artwork>
1395 <t>
1396 In GNS, users MAY own and manage their own zones.
1397 Each local zone SHOULD be associated with a single GNS label,
1398 but users MAY choose to use longer names consisting of
1399 multiple labels.
1400 If the name of a locally managed zone matches the suffix
1401 of the name to be resolved,
1402 resolution SHOULD start from the respective local zone:
1403 </t>
1404 <artwork name="" type="" align="left" alt=""><![CDATA[
1405Example name: www.example.gnu
1406Local zones:
1407fr = (d0,zk0)
1408gnu = (d1,zk1)
1409com = (d2,zk2)
1410...
1411=> Entry zone: zk1
1412=> Name to resolve from entry zone: www.example
1413 ]]></artwork>
1414 <t>
1415 Finally, additional "suffix to zone" mappings MAY be configured.
1416 Suffix to zone key mappings SHOULD be configurable through a local
1417 configuration file or database by the user or system administrator.
1418 The suffix MAY consist of multiple GNS labels concatenated with a
1419 ".". If multiple suffixes match the name to resolve, the longest
1420 matching suffix MUST BE used. The suffix length of two results
1421 cannot be equal, as this would indicate a misconfiguration.
1422 If both a locally managed zone and a configuration entry exist
1423 for the same suffix, the locally managed zone MUST have priority.
1424 </t>
1425 <artwork name="" type="" align="left" alt=""><![CDATA[
1426Example name: www.example.gnu
1427Local suffix mappings:
1428gnu = zk0
1429example.gnu = zk1
1430example.com = zk2
1431...
1432=> Entry zone: zk1
1433=> Name to resolve from entry zone: www
1434 ]]></artwork>
1435 </section>
1436 <section anchor="security" numbered="true" toc="default">
1437 <name>Security Considerations</name>
1438 <section anchor="security_crypto" numbered="true" toc="default">
1439 <name>Cryptography</name>
1440 <t>
1441 The security of cryptographic systems depends on both the strength of
1442 the cryptographic algorithms chosen and the strength of the keys used
1443 with those algorithms. The security also depends on the engineering
1444 of the protocol used by the system to ensure that there are no
1445 non-cryptographic ways to bypass the security of the overall system.
1446 </t>
1447 <t>
1448 This document concerns itself with the selection of cryptographic
1449 algorithms for use in GNS.
1450 The algorithms identified in this document are not known to be
1451 broken (in the cryptographic sense) at the current time, and
1452 cryptographic research so far leads us to believe that they are
1453 likely to remain secure into the foreseeable future. However, this
1454 isn't necessarily forever, and it is expected that new revisions of
1455 this document will be issued from time to time to reflect the current
1456 best practices in this area.
1457 </t>
1458 <t>
1459 GNS uses ECDSA over Curve25519. This is an unconventional choice,
1460 as ECDSA is usually used with other curves. However, traditional
1461 ECDSA curves are problematic for a range of reasons described in
1462 the Curve25519 and EdDSA papers. Using EdDSA directly is also
1463 not possible, as a hash function is used on the private key which
1464 destroys the linearity that the GNU Name System depends upon.
1465 We are not aware of anyone suggesting that using Curve25519 instead
1466 of another common curve of similar size would lower the security of
1467 ECDSA. GNS uses 256-bit curves because that way the encoded (public)
1468 keys fit into a single DNS label, which is good for usability.
1469 </t>
1470 </section>
1471 <section anchor="security_abuse" numbered="true" toc="default">
1472 <name>Abuse mitigation</name>
1473 <t>
1474 GNS names are UTF-8 strings. Consequently, GNS faces similar issues
1475 with respect to name spoofing as DNS does for internationalized
1476 domain names.
1477 In DNS, attackers may register similar sounding or looking
1478 names (see above) in order to execute phishing attacks.
1479 GNS zone administrators must take into account this attack vector and
1480 incorporate rules in order to mitigate it.
1481 </t>
1482 <t>
1483 Further, DNS can be used to combat illegal content on the internet
1484 by having the respective domains seized by authorities.
1485 However, the same mechanisms can also be abused in order to impose
1486 state censorship, which ist one of the motivations behind GNS.
1487 Hence, such a seizure is, by design, difficult to impossible in GNS.
1488 In particular, GNS does not support WHOIS (<xref target="RFC3912" />).
1489 </t>
1490 </section>
1491 <section anchor="security_keymanagement" numbered="true" toc="default">
1492 <name>Zone management</name>
1493 <t>
1494 In GNS, zone administrators need to manage and protect their zone
1495 keys. Once a zone key is lost it cannot be recovered. Once it is
1496 compromised it cannot be revoked (unless a revocation message was
1497 pre-calculated and is still available).
1498 Zone administrators, and for GNS this includes end-users, are
1499 required to responsibly and dilligently protect their cryptographic
1500 keys. Offline signing is in principle possible, but GNS does not
1501 support separate zone signing and key-signing keys
1502 (as in <xref target="RFC6781" />) in order to provide usable security.
1503 </t>
1504 <t>
1505 Similarly, users are required to manage their local root zone.
1506 In order to ensure integrity and availability or names, users must
1507 ensure that their local root zone information is not compromised or
1508 outdated.
1509 It can be expected that the processing of zone revocations and an
1510 initial root zone is provided with a GNS client implementation
1511 ("drop shipping").
1512 Extension and customization of the zone is at the full discretion of
1513 the user.
1514 </t>
1515 </section>
1516 <section anchor="security_dht" numbered="true" toc="default">
1517 <name>Impact of underlying DHT</name>
1518 <t>
1519 This document does not specifiy the properties of the underlying
1520 distributed hash table (DHT) which is required by any GNS
1521 implementation. For implementors, it is important to note that
1522 the properties of the DHT are directly inherited by the
1523 GNS implementation. This includes both security as well as
1524 other non-functional properties such as scalability and performance.
1525 Implementors should take great care when selecting or implementing
1526 a DHT for use in a GNS implementation.
1527 DHTs with string security and performance guarantees exist
1528 <xref target="R5N"/>.
1529 It should also be taken into consideration that GNS implementations
1530 which build upon different DHT overlays are unlikely to be
1531 interoperable with each other.
1532 </t>
1533 </section>
1534 <section anchor="security_rev" numbered="true" toc="default">
1535 <name>Revocations</name>
1536 <t>
1537 Zone administrators are advised to pre-generate zone revocations
1538 and securely store the revocation information in case the zone
1539 key is lost, compromised or replaced in the furture.
1540 Pre-calculated revocations may become invalid due to expirations
1541 or protocol changes such as epoch adjustments.
1542 Consequently, implementors and users must make precautions in order
1543 to manage revocations accordingly.
1544 </t>
1545 <t>
1546 Revocation payloads do NOT include a 'new' key for key replacement.
1547 Inclusion of such a key would have two major disadvantages:
1548 </t>
1549 <t>
1550 If revocation is used after a private key was compromised,
1551 allowing key replacement would be dangerous: if an
1552 adversary took over the private key, the adversary could then
1553 broadcast a revocation with a key replacement. For the replacement,
1554 the compromised owner would have no chance to issue even a
1555 revocation. Thus, allowing a revocation message to replace a private
1556 key makes dealing with key compromise situations worse.
1557 </t>
1558 <t>
1559 Sometimes, key revocations are used with the objective of changing
1560 cryptosystems. Migration to another cryptosystem by replacing keys
1561 via a revocation message would only be secure as long as both
1562 cryptosystems are still secure against forgery. Such a planned,
1563 non-emergency migration to another cryptosystem should be done by
1564 running zones for both ciphersystems in parallel for a while. The
1565 migration would conclude by revoking the legacy zone key only once
1566 it is deemed no longer secure, and hopefully after most users have
1567 migrated to the replacement.
1568 </t>
1569 </section>
1570 </section>
1571 <section anchor="gana" numbered="true" toc="default">
1572 <name>GANA Considerations</name>
1573 <t>
1574 GANA is requested to create an "GNU Name System Record Types" registry.
1575 The registry shall record for each entry:
1576 </t>
1577 <ul>
1578 <li>Name: The name of the record type (case-insensitive ASCII
1579 string, restricted to alphanumeric characters</li>
1580 <li>Number: 32-bit, above 65535</li>
1581 <li>Comment: Optionally, a brief English text describing the purpose of
1582 the record type (in UTF-8)</li>
1583 <li>Contact: Optionally, the contact information of a person to contact for
1584 further information</li>
1585 <li>References: Optionally, references describing the record type
1586 (such as an RFC)</li>
1587 </ul>
1588 <t>
1589 The registration policy for this sub-registry is "First Come First
1590 Served", as described in <xref target="RFC8126"/>.
1591 GANA is requested to populate this registry as follows:
1592 </t>
1593 <figure anchor="figure_rrtypenums">
1594 <artwork name="" type="" align="left" alt=""><![CDATA[
1595Number | Name | Contact | References | Description
1596-------+---------+---------+------------+-------------------------
159765536 | PKEY | N/A | [This.I-D] | GNS zone delegation
159865537 | NICK | N/A | [This.I-D] | GNS zone nickname
159965538 | LEHO | N/A | [This.I-D] | GNS legacy hostname
160065539 | VPN | N/A | [This.I-D] | VPN resolution
160165540 | GNS2DNS | N/A | [This.I-D] | Delegation to DNS
160265541 | BOX | N/A | [This.I-D] | Boxed record
1603 ]]></artwork>
1604 </figure>
1605 <t>
1606 GANA is requested to amend the "GNUnet Signature Purpose" registry
1607 as follows:
1608 </t>
1609 <figure anchor="figure_purposenums">
1610 <artwork name="" type="" align="left" alt=""><![CDATA[
1611Purpose | Name | References | Description
1612--------+-----------------+------------+--------------------------
1613 3 | GNS_REVOCATION | [This.I-D] | GNS zone key revocation
1614 15 | GNS_RECORD_SIGN | [This.I-D] | GNS record set signature
1615 ]]></artwork>
1616 </figure>
1617 </section>
1618 <!-- gana -->
1619 <section>
1620 <name>Test Vectors</name>
1621 <t>
1622 The following represents a test vector for a record set with a DNS
1623 record of type "A" as well as a GNS record of type "PKEY"
1624 under the label "test".
1625 </t>
1626 <artwork name="" type="" align="left" alt="">
1627 <![CDATA[
1628Zone private key (d):
1629WGb/eoy8BDWvaK2vRab0xTlqvS0+PeS5HG5Rh4z4cWI=
1630Zone public key (zk):
1631n7TNZeJ+Ks6wQymnwjZXR/cj0ae8NZMZ/PcuDVrONAo=
1632Label: test
1633RRCOUNT: 2
1634
1635Record #0
1636EXPIRATION: 1589117218087117
1637DATA_SIZE: 4
1638TYPE: 1
1639FLAGS: 0
1640DATA (base64):
1641AQIDBA==
1642DATA (Human readable):
16431.2.3.4
1644
1645Record #1
1646EXPIRATION: 1589117218087117
1647DATA_SIZE: 32
1648TYPE: 65536
1649FLAGS: 2
1650DATA (base64):
1651+AT14h9SMRAwkor+azlHpE8DkvsUyeQyN49NEmsOXew=
1652DATA (Human readable):
1653Z02FBRGZA8RH0C4JHBZ6PEA7MH7G74QV2K4Y8CHQHX6H4TREBQP0
1654
1655RDATA:
1656AAWlSy9KYM0AAAAEAAAAAQAAAAABAgMEAAWlSy9KYM0AAAAgAAEAAAAAAAL4BPXi
1657H1IxEDCSiv5rOUekTwOS+xTJ5DI3j00Saw5d7AAAAAAAAAAAAAAAAAAAAAAAAAAA
1658AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
1659
1660BDATA:
16615e5936fttKU61GByslXav57Zgi4rac2N0F6VJCKC7NVn1YPJyiL/0+f2vZSUfHpk
1662ZfRPv9clYgzO4m+PdRcYFpkG0vqmrFnDNJQRd/y9V2Wfg4ud82FK3CT9lcMpu6Sd
1663fbZyE8PmL7cySfdMa/RsNWCVAES98UOvNJ7CaBDJlY2mb6iA
1664
1665RRBLOCK:
1666Cqk3xJHTNxM1EE69iH33z0dK78FrhK+gUHMIUY//WHYCPZmbdgJc5Avb9uVTAAyT
16675No5uINZwxXuWpL72Xh4IIqWAE/BdKHS9deQusO6CSiZN1swM5zsupJq1qjgHusG
1668AAAAlAAAAA8ABaVLL0pgzeXufd+n7bSlOtRgcrJV2r+e2YIuK2nNjdBelSQiguzV
1669Z9WDycoi/9Pn9r2UlHx6ZGX0T7/XJWIMzuJvj3UXGBaZBtL6pqxZwzSUEXf8vVdl
1670n4OLnfNhStwk/ZXDKbuknX22chPD5i+3Mkn3TGv0bDVglQBEvfFDrzSewmgQyZWN
1671pm+ogA==
1672 ]]>
1673 </artwork>
1674 <t>
1675 The following is an example revocation for a zone:
1676 </t>
1677 <artwork name="" type="" align="left" alt="">
1678 <![CDATA[
1679Zone private key (d):
1680EJJaW7UymipsU6IkFFdt/jkE/kNd22IAyqNb3sMRk2g=
1681
1682Zone public key (zk):
1683fUBR/J2vCuXXv70BdSi/J0G8n+qxs7LctC34hJaQ7S4=
1684
1685Difficulty (5 base difficulty + 2 epochs): 7
1686
1687Proof:
1688AAWlWugT9IoAWl4FAQAAAG40PmjcaH+LbjQ+aNxogM1uND5o3GiBPG40PmjcaIKM
1689bjQ+aNxogzhuND5o3GiDvG40PmjcaIPLbjQ+aNxohAFuND5o3GiEVm40PmjcaIRb
1690bjQ+aNxohF1uND5o3GiE2W40PmjcaIV1bjQ+aNxohfluND5o3GiGEG40PmjcaIY1
1691bjQ+aNxohvRuND5o3GiHgW40PmjcaIezbjQ+aNxoiABuND5o3GiIF240PmjcaIgf
1692bjQ+aNxoiD1uND5o3GiIVW40PmjcaIilbjQ+aNxoiLBuND5o3GiIzm40PmjcaIj/
1693bjQ+aNxoiQduND5o3GiJgW40PmjcaIm8bjQ+aNxoidILkGuzZsdbclNZaOXvMPrC
1694O+EHuA6+tacFI1bhURGBowFyaFZjgi3mOOdlKFnkJ0vnauZPIb12C3V6qhoHmhNy
1695fUBR/J2vCuXXv70BdSi/J0G8n+qxs7LctC34hJaQ7S4=
1696 ]]>
1697 </artwork>
1698 </section>
1699 </middle>
1700 <back>
1701 <references>
1702 <name>Normative References</name>
1703
1704 &RFC1034;
1705 &RFC1035;
1706 &RFC2782;
1707 &RFC2119;
1708 &RFC3629;
1709 &RFC3826;
1710 &RFC3912;
1711 &RFC5869;
1712 &RFC5890;
1713 &RFC5891;
1714 &RFC6781;
1715 &RFC6895;
1716 &RFC6979;
1717 &RFC7748;
1718 &RFC8032;
1719 &RFC8126;
1720
1721 <reference anchor="TWOFISH">
1722 <front>
1723 <title>
1724 The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition
1725 </title>
1726 <author initials="B." surname="Schneier" fullname="B. Schneier">
1727 <organization/>
1728 </author>
1729 <date year="1999" month="March"/>
1730 </front>
1731 </reference>
1732 <reference anchor="GNS" target="https://doi.org/10.1007/978-3-319-12280-9_9">
1733 <front>
1734 <title>A Censorship-Resistant, Privacy-Enhancing and Fully Decentralized Name System</title>
1735 <author initials="M." surname="Wachs" fullname="Matthias Wachs">
1736 <organization>Technische Universität München</organization>
1737 </author>
1738
1739 <author initials="M." surname="Schanzenbach" fullname="Martin Schanzenbach">
1740 <organization>Technische Universität München</organization>
1741 </author>
1742
1743 <author initials="C." surname="Grothoff"
1744 fullname="Christian Grothoff">
1745 <organization>Technische Universität München</organization>
1746 </author>
1747 <date year="2014"/>
1748 </front>
1749 </reference>
1750 <reference anchor="R5N" target="https://doi.org/10.1109/ICNSS.2011.6060022">
1751 <front>
1752 <title>R5N: Randomized recursive routing for restricted-route networks</title>
1753 <author initials="N. S." surname="Evans" fullname="Nathan S. Evans">
1754 <organization>Technische Universität München</organization>
1755 </author>
1756
1757 <author initials="C." surname="Grothoff"
1758 fullname="Christian Grothoff">
1759 <organization>Technische Universität München</organization>
1760 </author>
1761 <date year="2011"/>
1762 </front>
1763 </reference>
1764
1765
1766 <reference anchor="Argon2" target="https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/">
1767 <front>
1768 <title>The memory-hard Argon2 password hash and proof-of-work function</title>
1769 <author initials="A." surname="Biryukov" fullname="Alex Biryukov">
1770 <organization>University of Luxembourg</organization>
1771 </author>
1772
1773 <author initials="D." surname="Dinu" fullname="Daniel Dinu">
1774 <organization>University of Luxembourg</organization>
1775 </author>
1776
1777 <author initials="D." surname="Khovratovich"
1778 fullname="Dmitry Khovratovich">
1779 <organization>ABDK Consulting</organization>
1780 </author>
1781 <author initials="S." surname="Josefsson"
1782 fullname="Simon Josefsson">
1783 <organization>SJD AB</organization>
1784 </author>
1785 <date year="2020" month="March"/>
1786 <abstract>
1787 <t>
1788 This document describes the Argon2 memory-hard function for
1789 password hashing and proof-of-work applications. We provide an
1790 implementer-oriented description with
1791 test vectors. The purpose is to simplify adoption of Argon2 for
1792 Internet protocols. This document is a product of the Crypto Forum Research Group (CFRG)
1793 in the IRTF.
1794 </t>
1795 </abstract>
1796 </front>
1797 </reference>
1798 <!-- <reference anchor="ISO20022">
1799 <front>
1800 <title>ISO 20022 Financial Services - Universal financial industry message scheme</title>
1801 <author>
1802 <organization>International Organization for Standardization</organization>
1803 <address>
1804 <uri>http://www.iso.ch</uri>
1805 </address>
1806 </author>
1807 <date month="May" year="2013"/>
1808 </front>
1809 </reference>-->
1810 </references>
1811 <!-- Change Log
1812 v00 2017-07-23 MS Initial version
1813 -->
1814 </back>
1815 </rfc>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-01 03:08:51 +0000