draft-schanzen-gns-00.xml (80719B)
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[ 189 0 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[ 305 0 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[ 334 0 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[ 379 0 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[ 420 0 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[ 459 0 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[ 501 0 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[ 557 PRK_h := HKDF-Extract ("key-derivation", zk) 558 h := HKDF-Expand (PRK_h, label | "gns", 512 / 8) 559 d_h := h * d mod L 560 zk_h := h mod L * zk 561 q := 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[ 631 0 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[ 718 0 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[ 782 PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk) 783 PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk) 784 K := HKDF-Expand (PRK_k, label, 512 / 8); 785 IV := 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[ 799 0 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[ 820 0 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[ 838 RDATA := AES(K[0:31], IV[0:15], 839 TWOFISH(K[32:63], IV[16:31], BDATA)) 840 BDATA := 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 ".<Base32(zk)>", 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 ".<Base32(zk)>"). 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[ 1089 Query: alice.doe (type=A) 1090 Result: 1091 A: 1.2.3.4 1092 NICK: 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[ 1105 Query: alice.doe (type=A) 1106 Result: 1107 A: 1.2.3.4 1108 NICK: 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[ 1149 S := "gnunet-revocation-proof-of-work" /* Salt */ 1150 t := 3 /* Iterations */ 1151 m := 1024 /* Memory size, 1 MiB */ 1152 T := 64 /* Tag (=output) length in bytes */ 1153 p := 1 /* Parallelization parameter */ 1154 v := 0x13 /* Version */ 1155 y := 0 /* Type (Argon2d) */ 1156 X, 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[ 1164 0 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[ 1232 0 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[ 1309 0 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[ 1391 Example 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[ 1405 Example name: www.example.gnu 1406 Local zones: 1407 fr = (d0,zk0) 1408 gnu = (d1,zk1) 1409 com = (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[ 1426 Example name: www.example.gnu 1427 Local suffix mappings: 1428 gnu = zk0 1429 example.gnu = zk1 1430 example.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[ 1595 Number | Name | Contact | References | Description 1596 -------+---------+---------+------------+------------------------- 1597 65536 | PKEY | N/A | [This.I-D] | GNS zone delegation 1598 65537 | NICK | N/A | [This.I-D] | GNS zone nickname 1599 65538 | LEHO | N/A | [This.I-D] | GNS legacy hostname 1600 65539 | VPN | N/A | [This.I-D] | VPN resolution 1601 65540 | GNS2DNS | N/A | [This.I-D] | Delegation to DNS 1602 65541 | 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[ 1611 Purpose | 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[ 1628 Zone private key (d): 1629 WGb/eoy8BDWvaK2vRab0xTlqvS0+PeS5HG5Rh4z4cWI= 1630 Zone public key (zk): 1631 n7TNZeJ+Ks6wQymnwjZXR/cj0ae8NZMZ/PcuDVrONAo= 1632 Label: test 1633 RRCOUNT: 2 1634 1635 Record #0 1636 EXPIRATION: 1589117218087117 1637 DATA_SIZE: 4 1638 TYPE: 1 1639 FLAGS: 0 1640 DATA (base64): 1641 AQIDBA== 1642 DATA (Human readable): 1643 1.2.3.4 1644 1645 Record #1 1646 EXPIRATION: 1589117218087117 1647 DATA_SIZE: 32 1648 TYPE: 65536 1649 FLAGS: 2 1650 DATA (base64): 1651 +AT14h9SMRAwkor+azlHpE8DkvsUyeQyN49NEmsOXew= 1652 DATA (Human readable): 1653 Z02FBRGZA8RH0C4JHBZ6PEA7MH7G74QV2K4Y8CHQHX6H4TREBQP0 1654 1655 RDATA: 1656 AAWlSy9KYM0AAAAEAAAAAQAAAAABAgMEAAWlSy9KYM0AAAAgAAEAAAAAAAL4BPXi 1657 H1IxEDCSiv5rOUekTwOS+xTJ5DI3j00Saw5d7AAAAAAAAAAAAAAAAAAAAAAAAAAA 1658 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= 1659 1660 BDATA: 1661 5e5936fttKU61GByslXav57Zgi4rac2N0F6VJCKC7NVn1YPJyiL/0+f2vZSUfHpk 1662 ZfRPv9clYgzO4m+PdRcYFpkG0vqmrFnDNJQRd/y9V2Wfg4ud82FK3CT9lcMpu6Sd 1663 fbZyE8PmL7cySfdMa/RsNWCVAES98UOvNJ7CaBDJlY2mb6iA 1664 1665 RRBLOCK: 1666 Cqk3xJHTNxM1EE69iH33z0dK78FrhK+gUHMIUY//WHYCPZmbdgJc5Avb9uVTAAyT 1667 5No5uINZwxXuWpL72Xh4IIqWAE/BdKHS9deQusO6CSiZN1swM5zsupJq1qjgHusG 1668 AAAAlAAAAA8ABaVLL0pgzeXufd+n7bSlOtRgcrJV2r+e2YIuK2nNjdBelSQiguzV 1669 Z9WDycoi/9Pn9r2UlHx6ZGX0T7/XJWIMzuJvj3UXGBaZBtL6pqxZwzSUEXf8vVdl 1670 n4OLnfNhStwk/ZXDKbuknX22chPD5i+3Mkn3TGv0bDVglQBEvfFDrzSewmgQyZWN 1671 pm+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[ 1679 Zone private key (d): 1680 EJJaW7UymipsU6IkFFdt/jkE/kNd22IAyqNb3sMRk2g= 1681 1682 Zone public key (zk): 1683 fUBR/J2vCuXXv70BdSi/J0G8n+qxs7LctC34hJaQ7S4= 1684 1685 Difficulty (5 base difficulty + 2 epochs): 7 1686 1687 Proof: 1688 AAWlWugT9IoAWl4FAQAAAG40PmjcaH+LbjQ+aNxogM1uND5o3GiBPG40PmjcaIKM 1689 bjQ+aNxogzhuND5o3GiDvG40PmjcaIPLbjQ+aNxohAFuND5o3GiEVm40PmjcaIRb 1690 bjQ+aNxohF1uND5o3GiE2W40PmjcaIV1bjQ+aNxohfluND5o3GiGEG40PmjcaIY1 1691 bjQ+aNxohvRuND5o3GiHgW40PmjcaIezbjQ+aNxoiABuND5o3GiIF240PmjcaIgf 1692 bjQ+aNxoiD1uND5o3GiIVW40PmjcaIilbjQ+aNxoiLBuND5o3GiIzm40PmjcaIj/ 1693 bjQ+aNxoiQduND5o3GiJgW40PmjcaIm8bjQ+aNxoidILkGuzZsdbclNZaOXvMPrC 1694 O+EHuA6+tacFI1bhURGBowFyaFZjgi3mOOdlKFnkJ0vnauZPIb12C3V6qhoHmhNy 1695 fUBR/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>