idnits 2.17.1 draft-schanzen-gns-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 163 has weird spacing: '... ztype is th...' == Line 171 has weird spacing: '... zk is the ...' == Line 174 has weird spacing: '... zid is the...' == Line 219 has weird spacing: '...) -> zk is a ...' == Line 226 has weird spacing: '...> bdata is a...' == (7 more instances...) -- The document date (18 October 2020) is 1279 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '31' on line 542 -- Looks like a reference, but probably isn't: '0' on line 548 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Independent Stream M. Schanzenbach 3 Internet-Draft GNUnet e.V. 4 Intended status: Informational C. Grothoff 5 Expires: 21 April 2021 Berner Fachhochschule 6 B. Fix 7 GNUnet e.V. 8 18 October 2020 10 The GNU Name System 11 draft-schanzen-gns-02 13 Abstract 15 This document contains the GNU Name System (GNS) technical 16 specification. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 21 April 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Zone Types . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Resource Records . . . . . . . . . . . . . . . . . . . . . . 6 55 5. Record Types . . . . . . . . . . . . . . . . . . . . . . . . 8 56 5.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 5.2. EDKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 11 58 5.3. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . . . 13 59 5.4. LEHO . . . . . . . . . . . . . . . . . . . . . . . . . . 14 60 5.5. NICK . . . . . . . . . . . . . . . . . . . . . . . . . . 15 61 5.6. BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 62 5.7. VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 63 6. Publishing Records . . . . . . . . . . . . . . . . . . . . . 17 64 6.1. DHT Key Derivations . . . . . . . . . . . . . . . . . . . 17 65 6.2. Resource Records Block . . . . . . . . . . . . . . . . . 17 66 6.3. Record Data Encryption and Decryption . . . . . . . . . . 19 67 7. Internationalization and Character Encoding . . . . . . . . . 20 68 8. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 20 69 8.1. Recursion . . . . . . . . . . . . . . . . . . . . . . . . 20 70 8.2. Record Processing . . . . . . . . . . . . . . . . . . . . 21 71 8.2.1. Encountering zone delegation records . . . . . . . . 22 72 8.2.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 22 73 8.2.3. CNAME . . . . . . . . . . . . . . . . . . . . . . . . 23 74 8.2.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 23 75 8.2.5. VPN . . . . . . . . . . . . . . . . . . . . . . . . . 24 76 8.2.6. NICK . . . . . . . . . . . . . . . . . . . . . . . . 24 77 9. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 25 78 10. Determining the Root Zone and Zone Governance . . . . . . . . 29 79 11. Security Considerations . . . . . . . . . . . . . . . . . . . 30 80 11.1. Cryptography . . . . . . . . . . . . . . . . . . . . . . 30 81 11.2. Abuse mitigation . . . . . . . . . . . . . . . . . . . . 31 82 11.3. Zone management . . . . . . . . . . . . . . . . . . . . 32 83 11.4. Impact of underlying DHT . . . . . . . . . . . . . . . . 32 84 11.5. Revocations . . . . . . . . . . . . . . . . . . . . . . 32 85 12. GANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 86 13. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 34 87 14. Normative References . . . . . . . . . . . . . . . . . . . . 38 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 90 1. Introduction 92 The Domain Name System (DNS) is a unique distributed database and a 93 vital service for most Internet applications. While DNS is 94 distributed, it relies on centralized, trusted registrars to provide 95 globally unique names. As the awareness of the central role DNS 96 plays on the Internet rises, various institutions are using their 97 power (including legal means) to engage in attacks on the DNS, thus 98 threatening the global availability and integrity of information on 99 the Internet. 101 DNS was not designed with security as a goal. This makes it very 102 vulnerable, especially to attackers that have the technical 103 capabilities of an entire nation state at their disposal. This 104 specification describes a censorship-resistant, privacy-preserving 105 and decentralized name system: The GNU Name System (GNS). It is 106 designed to provide a secure alternative to DNS, especially when 107 censorship or manipulation is encountered. GNS can bind names to any 108 kind of cryptographically secured token, enabling it to double in 109 some respects as even as an alternative to some of today's Public Key 110 Infrastructures, in particular X.509 for the Web. 112 This document contains the GNU Name System (GNS) technical 113 specification of the GNU Name System [GNS], a fully decentralized and 114 censorship-resistant name system. GNS provides a privacy-enhancing 115 alternative to the Domain Name System (DNS). The design of GNS 116 incorporates the capability to integrate and coexist with DNS. GNS 117 is based on the principle of a petname system and builds on ideas 118 from the Simple Distributed Security Infrastructure (SDSI), 119 addressing a central issue with the decentralized mapping of secure 120 identifiers to memorable names: namely the impossibility of providing 121 a global, secure and memorable mapping without a trusted authority. 122 GNS uses the transitivity in the SDSI design to replace the trusted 123 root with secure delegation of authority thus making petnames useful 124 to other users while operating under a very strong adversary model. 126 This document defines the normative wire format of resource records, 127 resolution processes, cryptographic routines and security 128 considerations for use by implementors. GNS requires a distributed 129 hash table (DHT) for record storage. Specification of the DHT is out 130 of scope of this document. 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 2. Zones 138 A zone in GNS is defined by a zone type "ztype" that identifies a 139 cryptosystem and a public/private key pair "(d,zk)", where "d" is the 140 private key and "zk" the corresponding public key in the public key 141 cipher identified by the "ztype". The contents of a zone are 142 cryptographically signed before being published a distributed hash 143 table (DHT). Records are grouped by their label and encrypted 144 (Section 6.3) using an encryption key derived from the label and the 145 zone public key. Instead of the zone private key "d", the signature 146 MUST be created using a blinded public/private key pair "d'" and 147 "zk'". This blinding is realized using a hierarchical deterministic 148 key derivation (HDKD) scheme. Such a scheme allows the deterministic 149 derivation of keys from the original public and private zone keys 150 using "label" values. Specifically, the zone owner can derive 151 private keys "d'", and a resolver to derive the corresponding public 152 keys "zk'". Using different "label" values in the derivation results 153 in different keys. Without knowledge of the "label" values, the 154 different derivations are unlinkable both to the original key and to 155 each other. This prevents zone enumeration and requires knowledge of 156 both "zk" and the "label" to confirm affiliation with a specific 157 zone. At the same time, the blinded "zk'" provides nodes with the 158 ability to verifiy the integrity of the published information without 159 disclosing the originating zone. 161 The following variables are associated with a zone in GNS: 163 ztype is the unique type of the zone type as registered in the 164 GNUnet Assigned Numbers Authority [GANA]. The zone type 165 determines which cryptosystem is used for the asymmetric and 166 symmetric key operations of the zone. A 32-bit number. 168 d is the private zone key. The specific format depends on the zone 169 type. 171 zk is the public zone key. The specific format depends on the zone 172 type. 174 zid is the unique public identifier of a zone. It consists of the 175 "ztype" and the public zone key "zk". 177 zTLD is a string which encodes the "ztype" as well as the zone key 178 "zk" into a domain name. The "zTLD" is used as a globally unique 179 reference to a specific namespace in the process of name 180 resolution. 182 The "zid" wire format is defined as follows: 184 0 8 16 24 32 40 48 56 185 +-----+-----+-----+-----+-----+-----+-----+-----+ 186 | ZONE TYPE | PUBLIC ZONE KEY / 187 +-----+-----+-----+-----+ / 188 / / 189 / / 191 Figure 1 193 For the string representation of the "zid", we use a base-32 encoding 194 "StringEncode". However, instead of following [RFC4648] we base our 195 character map on the optical character recognition friendly proposal 196 of Crockford [CrockfordB32]. The only difference to Crockford is 197 that the letter "U" decodes to the same base-32 value as the letter 198 "V" (27). 200 zkl := 202 If "zkl" is less than 63 characters, it is also the "zTLD". If the 203 resulting "zkl" should be longer than 63 characters, the string must 204 be divided into smaller labels separated by the label separator ".". 205 Here, the most significant bytes of the "zid" must be contained in 206 the rightmost label of the resulting string and the least significant 207 bytes in the leftmost label of the resulting string. For example, 208 assuming a "zkl" of 130 characters, the encoding would be: 210 zTLD := zkl[126:129].zkl[63:125].zkl[0:62] 212 3. Zone Types 214 A zone type identifies a family of eight functions: 216 Private-KeyGen() -> d is a function to generate a fresh private key 217 "d". 219 Public-KeyGen(d) -> zk is a function to derive a public key "zk" 220 from a private key "d". 222 HDKD-Private(d,label) -> d' is an HDKD function which blinds a 223 private zone key "d" using "label", resulting in another private 224 key which can be used to create cryptographic signatures. 226 S-Encrypt(zk,label,nonce,expiration,rdata) -> bdata is a 227 deterministic symmetric encryption function which encrypts the 228 record data "rdata" based on key material derived from "zk", 229 "label", "nonce" and "expiration". A deterministic encryption 230 scheme is required to improve performance by leveraging caching 231 features of DHTs. 233 Sign(d',bdata) -> sig is a function to sign "bdata" using the 234 (blinded) private key "d'", yielding an unforgable cryptographic 235 signature "sig". 237 HDKD-Public(zk,label) -> zk' is a HDKD function which blinds a 238 public zone key "zk" using "label". "zk" and "zk'" must be 239 unlinkable. Furthermore, blinding "zk" with different values for 240 "label" must result in unlinkable different resulting values for 241 "zk'". 243 Verify(zk',bdata,sig) -> valid is a function to verify the signature 244 "sig" was created by the a private key "d'" derived from "d" and 245 "label" if "zk'" was derived from the corresponding to "zk := 246 Public-Keygen(d)" and "label". The function returns "true" if the 247 signature is valid, and otherwise "false". 249 S-Decrypt(zk,label,nonce,expiration,bdata) -> rdata is a symmetric 250 encryption function which decrypts the encrypted record data 251 "bdata" based on key material derived from "zk", "label", "nonce" 252 and "expiration". 254 Zone types are identified by a 32-bit resource record type number. 255 Resource record types are discussed in the next section. 257 4. Resource Records 259 A GNS implementor MUST provide a mechanism to create and manage 260 resource records for local zones. A local zone is established by 261 selecting a zone type and creating a zone key pair. Implementations 262 SHOULD select a secure zone type automatically and not leave the zone 263 type selection to the user. Records may be added to each zone, hence 264 a (local) persistency mechanism for resource records and zones must 265 be provided. This local zone database is used by the GNS resolver 266 implementation and to publish record information. 268 A GNS resource record holds the data of a specific record in a zone. 269 The resource record format is defined as follows: 271 0 8 16 24 32 40 48 56 272 +-----+-----+-----+-----+-----+-----+-----+-----+ 273 | EXPIRATION | 274 +-----+-----+-----+-----+-----+-----+-----+-----+ 275 | DATA SIZE | TYPE | 276 +-----+-----+-----+-----+-----+-----+-----+-----+ 277 | FLAGS | DATA / 278 +-----+-----+-----+-----+ / 279 / / 280 / / 281 Figure 2 283 where: 285 EXPIRATION denotes the absolute 64-bit expiration date of the 286 record. In microseconds since midnight (0 hour), January 1, 1970 287 in network byte order. 289 DATA SIZE denotes the 32-bit size of the DATA field in bytes and in 290 network byte order. 292 TYPE is the 32-bit resource record type. This type can be one of 293 the GNS resource records as defined in Section 4 or a DNS record 294 type as defined in [RFC1035] or any of the complementary 295 standardized DNS resource record types. This value must be stored 296 in network byte order. Note that values below 2^16 are reserved 297 for allocation via IANA ([RFC6895]), while values above 2^16 are 298 allocated by the GNUnet Assigned Numbers Authority [GANA]. 300 FLAGS is a 32-bit resource record flags field (see below). 302 DATA the variable-length resource record data payload. The contents 303 are defined by the respective type of the resource record. 305 Flags indicate metadata surrounding the resource record. A flag 306 value of 0 indicates that all flags are unset. The following 307 illustrates the flag distribution in the 32-bit flag value of a 308 resource record: 310 ... 5 4 3 2 1 0 311 ------+--------+--------+--------+--------+--------+ 312 / ... | SHADOW | EXPREL | SUPPL | PRIVATE| / | 313 ------+--------+--------+--------+--------+--------+ 315 Figure 3 317 where: 319 SHADOW If this flag is set, this record should be ignored by 320 resolvers unless all (other) records of the same record type have 321 expired. Used to allow zone publishers to facilitate good 322 performance when records change by allowing them to put future 323 values of records into the DHT. This way, future values can 324 propagate and may be cached before the transition becomes active. 326 EXPREL The expiration time value of the record is a relative time 327 (still in microseconds) and not an absolute time. This flag 328 should never be encountered by a resolver for records obtained 329 from the DHT, but might be present when a resolver looks up 330 private records of a zone hosted locally. 332 SUPPL This is a supplemental record. It is provided in addition to 333 the other records. This flag indicates that this record is not 334 explicitly managed alongside the other records under the 335 respective name but may be useful for the application. This flag 336 should only be encountered by a resolver for records obtained from 337 the DHT. 339 PRIVATE This is a private record of this peer and it should thus not 340 be published in the DHT. Thus, this flag should never be 341 encountered by a resolver for records obtained from the DHT. 342 Private records should still be considered just like regular 343 records when resolving labels in local zones. 345 5. Record Types 347 A registry of GNS Record Types is described in Section 12. The 348 registration policy for this registry is "First Come First Served", 349 as described in [RFC8126]. 351 5.1. PKEY 353 In GNS, a delegation of a label to a zone of type "PKEY" is 354 represented through a PKEY record. The PKEY number is a zone type 355 and thus also implies the cryptosystem for the zone that is being 356 delegated to. A PKEY resource record contains the public key of the 357 zone to delegate to. A PKEY record MUST be the only record under a 358 label. No other records are allowed. A PKEY DATA entry has the 359 following format: 361 0 8 16 24 32 40 48 56 362 +-----+-----+-----+-----+-----+-----+-----+-----+ 363 | PUBLIC KEY | 364 | | 365 | | 366 | | 367 +-----+-----+-----+-----+-----+-----+-----+-----+ 369 Figure 4 371 where: 373 PUBLIC KEY A 256-bit ECDSA zone key. 375 For PKEY zones the zone key material is derived using the curve 376 parameters of the twisted edwards representation of Curve25519 377 [RFC7748] (a.k.a. edwards25519) with the ECDSA scheme ([RFC6979]). 378 Consequently , we use the following naming convention for our 379 cryptographic primitives for PKEY zones: 381 d is a 256-bit ECDSA private zone key. 383 zk is the ECDSA public zone key corresponding to d. It is defined 384 in [RFC6979] as the curve point d*G where G is the group generator 385 of the elliptic curve. The public key is used to uniquely 386 identify a GNS zone and is referred to as the "zone key". 388 p is the prime of edwards25519 as defined in [RFC7748], i.e. 2^255 389 - 19. 391 G is the group generator (X(P),Y(P)) of edwards25519 as defined in 392 [RFC7748]. 394 L is the prime-order subgroup of edwards25519 in [RFC7748]. 396 The "zid" of a PKEY is 32 + 4 bytes in length. This means that a 397 "zTLD" will always fit into a single label and does not need any 398 further conversion. 400 Given a label, the output d' of the HDKD-Private(d,label) function 401 for zone key blinding is calculated as follows for PKEY zones: 403 zk := d * G 404 PRK_h := HKDF-Extract ("key-derivation", zk) 405 h := HKDF-Expand (PRK_h, label | "gns", 512 / 8) 406 d' := h * d mod L 408 Equally, given a label, the output zk' of the HDKD-Public(zk,label) 409 function is calculated as follows for PKEY zones: 411 PRK_h := HKDF-Extract ("key-derivation", zk) 412 h := HKDF-Expand (PRK_h, label | "gns", 512 / 8) 413 zk' := h mod L * zk 415 The PKEY cryptosystem uses a hash-based key derivation function 416 (HKDF) as defined in [RFC5869], using HMAC-SHA512 for the extraction 417 phase and HMAC-SHA256 for the expansion phase. "PRK_h" is key 418 material retrieved using an HKDF using the string "key-derivation" as 419 salt and the public zone key "zk" as initial keying material. "h" is 420 the 512-bit HKDF expansion result. The expansion info input is a 421 concatenation of the label and string "gns". "label" is a UTF-8 422 string under which the resource records are published. 424 We point out that the multiplication of "zk" with "h" is a point 425 multiplication, while the multiplication of "d" with "h" is a scalar 426 multiplication. 428 The Sign() and Verify() functions for PKEY zones are implemented 429 using 512-bit ECDSA deterministic signatures as specified in 430 [RFC6979]. 432 The S-Encrypt() and S-Decrypt() functions use AES in counter mode as 433 defined in [MODES] (CTR-AES-256): 435 RDATA := CTR-AES256(K, IV, BDATA) 436 BDATA := CTR-AES256(K, IV, RDATA) 438 The key "K" and counter "IV" are derived from the record "label" and 439 the zone key "zk" as follows: 441 PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk) 442 PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk) 443 K := HKDF-Expand (PRK_k, label, 256 / 8); 444 NONCE := HKDF-Expand (PRK_n, label, 32 / 8) 446 HKDF is a hash-based key derivation function as defined in [RFC5869]. 447 Specifically, HMAC-SHA512 is used for the extraction phase and HMAC- 448 SHA256 for the expansion phase. The output keying material is 32 449 octets (256 bits) for the symmetric key and 4 octets (32 bits) for 450 the nonce. The symmetric key "K" is a 256-bit AES [RFC3826] key. 452 The nonce is combined with a 64-bit initialization vector and a 453 32-bit block counter as defined in [RFC3686]. The block counter 454 begins with the value of 1, and it is incremented to generate 455 subsequent portions of the key stream. The block counter is a 32-bit 456 integer value in network byte order. The initialization vector is 457 the expiration time of the resource record block in network byte 458 order. The resulting counter ("IV") wire format is as follows: 460 0 8 16 24 32 461 +-----+-----+-----+-----+ 462 | NONCE | 463 +-----+-----+-----+-----+ 464 | EXPIRATION | 465 | | 466 +-----+-----+-----+-----+ 467 | BLOCK COUNTER | 468 +-----+-----+-----+-----+ 470 Figure 5 472 5.2. EDKEY 474 In GNS, a delegation of a label to a zone of type "EDKEY" is 475 represented through a EDKEY record. The EDKEY number is a zone type 476 and thus also implies the cryptosystem for the zone that is being 477 delegated to. An EDKEY resource record contains the public key of 478 the zone to delegate to. A EDKEY record MUST be the only record 479 under a label. No other records are allowed. A EDKEY DATA entry has 480 the following format: 482 0 8 16 24 32 40 48 56 483 +-----+-----+-----+-----+-----+-----+-----+-----+ 484 | PUBLIC KEY | 485 | | 486 | | 487 | | 488 +-----+-----+-----+-----+-----+-----+-----+-----+ 490 Figure 6 492 where: 494 PUBLIC KEY A 256-bit EdDSA zone key. 496 For EDKEY zones the zone key material is derived using the curve 497 parameters of the twisted edwards representation of Curve25519 498 [RFC7748] (a.k.a. edwards25519) with the Ed25519-SHA-512 scheme 499 [ed25519]. Consequently , we use the following naming convention for 500 our cryptographic primitives for EDKEY zones: 502 d is a 256-bit EdDSA private zone key. 504 a is is an integer derived from "d" using the SHA512 hash function 505 as defined in [ed25519]. 507 zk is the EdDSA public zone key corresponding to "d". It is defined 508 in [ed25519] as the curve point "a*G" where "G" is the group 509 generator of the elliptic curve and "a" is an integer derived from 510 "d" using the SHA512 hash function. The public key is used to 511 uniquely identify a GNS zone and is referred to as the "zone key". 513 p is the prime of edwards25519 as defined in [RFC7748], i.e. 2^255 514 - 19. 516 G is the group generator (X(P),Y(P)) of edwards25519 as defined in 517 [RFC7748]. 519 L is the prime-order subgroup of edwards25519 in [RFC7748]. 521 The "zid" of an EDKEY is 32 + 4 bytes in length. This means that a 522 "zTLD" will always fit into a single label and does not need any 523 further conversion. 525 The "EDKEY" HDKD instantiation is based on [Tor224]. Given a label, 526 the output of the HDKD-Private function for zone key blinding is 527 calculated as follows for EDKEY zones: 529 zk := a * G 530 PRK_h := HKDF-Extract ("key-derivation", zk) 531 h := HKDF-Expand (PRK_h, label | "gns", 512 / 8) 532 h[31] &= 7 533 a1 := a / 8 /* 8 is the cofactor of Curve25519 */ 534 a2 := h * a1 mod L 535 a' = a2 * 8 /* 8 is the cofactor of Curve25519 */ 537 Equally, given a label, the output of the HDKD-Public function is 538 calculated as follows for PKEY zones: 540 PRK_h := HKDF-Extract ("key-derivation", zk) 541 h := HKDF-Expand (PRK_h, label | "gns", 512 / 8) 542 h[31] &= 7 // Implies h mod L == h 543 zk' := h * zk 545 We note that implementors must employ a constant time scalar 546 multiplication for the constructions above. Also, implementors must 547 ensure that the private key "a" is an ed25519 private key and 548 specifically that "a[0] & 7 == 0" holds. 550 The EDKEY cryptosystem uses a hash-based key derivation function 551 (HKDF) as defined in [RFC5869], using HMAC-SHA512 for the extraction 552 phase and HMAC-SHA256 for the expansion phase. "PRK_h" is key 553 material retrieved using an HKDF using the string "key-derivation" as 554 salt and the public zone key "zk" as initial keying material. "h" is 555 the 512-bit HKDF expansion result. The expansion info input is a 556 concatenation of the label and string "gns". The result of the HKDF 557 must be clamped. "a" is the 256-bit integer corresponding to the 558 256-bit private zone key "d". "label" is a UTF-8 string under which 559 the resource records are published. 561 We point out that the multiplication of "zk" with "h" is a point 562 multiplication, while the division and multiplication of "a" and "a1" 563 with the cofactor are integer operations. 565 Signatures for EDKEY zones using the derived private key "a'" are NOT 566 compliant with [ed25519]. Instead, signatures MUST be generated as 567 follows for any given message M and deterministic random-looking "r": 569 R := r * G 570 S := r + SHA512(R, zk', M) * a' mod L 572 A signature (R,S) is valid if the following holds: 574 SB == R + SHA512(R, zk', M) * A' 576 The S-Encrypt() and S-Decrypt() functions use AES in galois counter 577 mode as defined in [GCM] (GCM-AES-256): 579 RDATA := GCM-AES-256(K, IV, BDATA) 580 BDATA := GCM-AES-256(K, IV, RDATA) = CIPHERTEXT | GCM_TAG 582 The result of the GCM encryption function is the encrypted ciphertext 583 concatenated with the 128-bit GCM authentication tag "GCM_TAG". 584 Accordingly, the length of BDATA equals the length of the RDATA plus 585 the 16 octets of the authentication tag. 587 The key "K" and counter "IV" are derived from the record "label" and 588 the zone key "zk" as follows: 590 PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk) 591 PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk) 592 K := HKDF-Expand (PRK_k, label, 256 / 8); 593 IV := HKDF-Expand (PRK_n, label, 96 / 8) 595 HKDF is a hash-based key derivation function as defined in [RFC5869]. 596 Specifically, HMAC-SHA512 is used for the extraction phase and HMAC- 597 SHA256 for the expansion phase. The output keying material is 32 598 octets (256 bits) for the symmetric key and 12 octets (96 bits) for 599 the IV. The symmetric key "K" is a 256-bit AES [RFC3826] key. No 600 additional authenticated data (AAD) is used. 602 5.3. GNS2DNS 604 It is possible to delegate a label back into DNS through a GNS2DNS 605 record. The resource record contains a DNS name for the resolver to 606 continue with in DNS followed by a DNS server. Both names are in the 607 format defined in [RFC1034] for DNS names. A GNS2DNS DATA entry has 608 the following format: 610 0 8 16 24 32 40 48 56 611 +-----+-----+-----+-----+-----+-----+-----+-----+ 612 | DNS NAME | 613 / / 614 / / 615 | | 616 +-----+-----+-----+-----+-----+-----+-----+-----+ 617 | DNS SERVER NAME | 618 / / 619 / / 620 | | 621 +-----------------------------------------------+ 623 Figure 7 625 where: 627 DNS NAME The name to continue with in DNS (0-terminated). 629 DNS SERVER NAME The DNS server to use. May be an IPv4/IPv6 address 630 in dotted decimal form or a DNS name. It may also be a relative 631 GNS name ending with a "+" top-level domain. The value is UTF-8 632 encoded (also for DNS names) and 0-terminated. 634 5.4. LEHO 636 Legacy hostname records can be used by applications that are expected 637 to supply a DNS name on the application layer. The most common use 638 case is HTTP virtual hosting, which as-is would not work with GNS 639 names as those may not be globally unique. A LEHO resource record is 640 expected to be found together in a single resource record with an 641 IPv4 or IPv6 address. A LEHO DATA entry has the following format: 643 0 8 16 24 32 40 48 56 644 +-----+-----+-----+-----+-----+-----+-----+-----+ 645 | LEGACY HOSTNAME | 646 / / 647 / / 648 | | 649 +-----+-----+-----+-----+-----+-----+-----+-----+ 651 Figure 8 653 where: 655 LEGACY HOSTNAME A UTF-8 string (which is not 0-terminated) 656 representing the legacy hostname. 658 NOTE: If an application uses a LEHO value in an HTTP request header 659 (e.g. "Host:" header) it must be converted to a punycode 660 representation [RFC5891]. 662 5.5. NICK 664 Nickname records can be used by zone administrators to publish an 665 indication on what label this zone prefers to be referred to. This 666 is a suggestion to other zones what label to use when creating a 667 delegation record (Section 3) containing this zone's public zone key. 668 This record SHOULD only be stored under the empty label "@" but MAY 669 be returned with record sets under any label as a supplemental 670 record. Section 8.2.6 details how a resolver must process 671 supplemental and non-supplemental NICK records. A NICK DATA entry 672 has the following format: 674 0 8 16 24 32 40 48 56 675 +-----+-----+-----+-----+-----+-----+-----+-----+ 676 | NICKNAME | 677 / / 678 / / 679 | | 680 +-----+-----+-----+-----+-----+-----+-----+-----+ 682 Figure 9 684 where: 686 NICKNAME A UTF-8 string (which is not 0-terminated) representing the 687 preferred label of the zone. This string MUST NOT include a "." 688 character. 690 5.6. BOX 692 In GNS, every "." in a name delegates to another zone, and GNS 693 lookups are expected to return all of the required useful information 694 in one record set. This is incompatible with the special labels used 695 by DNS for SRV and TLSA records. Thus, GNS defines the BOX record 696 format to box up SRV and TLSA records and include them in the record 697 set of the label they are associated with. For example, a TLSA 698 record for "_https._tcp.example.org" will be stored in the record set 699 of "example.org" as a BOX record with service (SVC) 443 (https) and 700 protocol (PROTO) 6 (tcp) and record TYPE "TLSA". For reference, see 701 also [RFC2782]. A BOX DATA entry has the following format: 703 0 8 16 24 32 40 48 56 704 +-----+-----+-----+-----+-----+-----+-----+-----+ 705 | PROTO | SVC | TYPE | 706 +-----------+-----------------------------------+ 707 | RECORD DATA | 708 / / 709 / / 710 | | 711 +-----+-----+-----+-----+-----+-----+-----+-----+ 713 Figure 10 715 where: 717 PROTO the 16-bit protocol number, e.g. 6 for tcp. In network byte 718 order. 720 SVC the 16-bit service value of the boxed record, i.e. the port 721 number. In network byte order. 723 TYPE is the 32-bit record type of the boxed record. In network byte 724 order. 726 RECORD DATA is a variable length field containing the "DATA" format 727 of TYPE as defined for the respective TYPE in DNS. 729 5.7. VPN 731 A VPN DATA entry has the following format: 733 0 8 16 24 32 40 48 56 734 +-----+-----+-----+-----+-----+-----+-----+-----+ 735 | HOSTING PEER PUBLIC KEY | 736 | (256 bits) | 737 | | 738 | | 739 +-----------+-----------------------------------+ 740 | PROTO | SERVICE NAME | 741 +-----------+ + 742 / / 743 / / 744 | | 745 +-----+-----+-----+-----+-----+-----+-----+-----+ 747 Figure 11 749 where: 751 HOSTING PEER PUBLIC KEY is a 256-bit EdDSA public key identifying 752 the peer hosting the service. 754 PROTO the 16-bit protocol number, e.g. 6 for TCP. In network byte 755 order. 757 SERVICE NAME a shared secret used to identify the service at the 758 hosting peer, used to derive the port number requird to connect to 759 the service. The service name MUST be a 0-terminated UTF-8 760 string. 762 6. Publishing Records 764 GNS resource records are published in a distributed hash table (DHT). 765 We assume that a DHT provides two functions: GET(key) and 766 PUT(key,value). In GNS, resource records are grouped by their 767 respective labels, encrypted and published together in a single 768 resource records block (RRBLOCK) in the DHT under a key "q": PUT(q, 769 RRBLOCK). The key "q" which is derived from the zone key "zk" and 770 the respective "label" of the contained records. 772 6.1. DHT Key Derivations 774 Given a label, the DHT key "q" is derived as follows: 776 q := SHA512 (HDKD-Public(zk, label)) 778 label is a UTF-8 string under which the resource records are 779 published. 781 zk is the public zone key. 783 q Is the 512-bit DHT key under which the resource records block is 784 published. It is the SHA512 hash over the derived public zone 785 key. 787 6.2. Resource Records Block 789 GNS records are grouped by their labels and published as a single 790 block in the DHT. The grouped record sets MAY be paired with any 791 number of supplemental records. Supplemental records must have the 792 supplemental flag set (See Section 4). The contained resource 793 records are encrypted using a symmetric encryption scheme. A GNS 794 implementation must publish RRBLOCKs in accordance to the properties 795 and recommendations of the underlying DHT. This may include a 796 periodic refresh publication. A GNS RRBLOCK has the following 797 format: 799 0 8 16 24 32 40 48 56 800 +-----+-----+-----+-----+-----+-----+-----+-----+ 801 | ZONE TYPE | PUBLIC ZONE KEY | 802 +-----+-----+-----+-----+ (BLINDED) | 803 / / 804 / / 805 | | 806 +-----+-----+-----+-----+-----+-----+-----+-----+ 807 | SIGNATURE | 808 / / 809 / / 810 | | 811 +-----+-----+-----+-----+-----+-----+-----+-----+ 812 | SIZE | PURPOSE | 813 +-----+-----+-----+-----+-----+-----+-----+-----+ 814 | EXPIRATION | 815 +-----+-----+-----+-----+-----+-----+-----+-----+ 816 | BDATA / 817 / / 818 / | 819 +-----+-----+-----+-----+-----+-----+-----+-----+ 821 Figure 12 823 where: 825 ZONE TYPE is the 32-bit zone type. 827 ZONE PUBLIC KEY is the blinded public zone key "HDKD-Public(zk, 828 label)" to be used to verify SIGNATURE. 830 SIGNATURE The signature is computed over the data following the 831 PUBLIC KEY field. The signature is created using the Sign() 832 function of the cryptosystem of the zone and the derived private 833 key "HDKD-Private(d, label)" (see Section 3). 835 SIZE A 32-bit value containing the length of the signed data 836 following the PUBLIC KEY field in network byte order. This value 837 always includes the length of the fields SIZE (4), PURPOSE (4) and 838 EXPIRATION (8) in addition to the length of the BDATA. While a 839 32-bit value is used, implementations MAY refuse to publish blocks 840 beyond a certain size significantly below 4 GB. However, a 841 minimum block size of 62 kilobytes MUST be supported. 843 PURPOSE A 32-bit signature purpose flag. This field MUST be 15 (in 844 network byte order). 846 EXPIRATION Specifies when the RRBLOCK expires and the encrypted 847 block SHOULD be removed from the DHT and caches as it is likely 848 stale. However, applications MAY continue to use non-expired 849 individual records until they expire. The value MUST be set to 850 the expiration time of the resource record contained within this 851 block with the smallest expiration time. If a records block 852 includes shadow records, then the maximum expiration time of all 853 shadow records with matching type and the expiration times of the 854 non-shadow records is considered. This is a 64-bit absolute date 855 in microseconds since midnight (0 hour), January 1, 1970 in 856 network byte order. 858 BDATA The encrypted resource records with a total size of SIZE - 16. 860 6.3. Record Data Encryption and Decryption 862 A symmetric encryption scheme is used to encrypt the resource records 863 set RDATA into the BDATA field of a GNS RRBLOCK. The wire format of 864 the RDATA looks as follows: 866 0 8 16 24 32 40 48 56 867 +-----+-----+-----+-----+-----+-----+-----+-----+ 868 | RR COUNT | EXPIRA- / 869 +-----+-----+-----+-----+-----+-----+-----+-----+ 870 / -TION | DATA SIZE | 871 +-----+-----+-----+-----+-----+-----+-----+-----+ 872 | TYPE | FLAGS | 873 +-----+-----+-----+-----+-----+-----+-----+-----+ 874 | DATA / 875 / / 876 / | 877 +-----+-----+-----+-----+-----+-----+-----+-----+ 878 | EXPIRATION | 879 +-----+-----+-----+-----+-----+-----+-----+-----+ 880 | DATA SIZE | TYPE | 881 +-----+-----+-----+-----+-----+-----+-----+-----+ 882 | FLAGS | DATA / 883 +-----+-----+-----+-----+ / 884 / +-----------------------/ 885 / | / 886 +-----------------------+ / 887 / PADDING / 888 / / 890 Figure 13 892 where: 894 RR COUNT A 32-bit value containing the number of variable-length 895 resource records which are following after this field in network 896 byte order. 898 EXPIRATION, DATA SIZE, TYPE, FLAGS and DATA These fields were 899 defined in the resource record format in Section 4. There MUST be 900 a total of RR COUNT of these resource records present. 902 PADDING The padding MUST contain the value 0 in all octets. The 903 padding MUST ensure that the size of the RDATA WITHOUT the RR 904 COUNT field is a power of two. As a special exception, record 905 sets with (only) a zone delegation record type are never padded. 906 Note that a record set with a delegation record MUST NOT contain 907 other records. 909 7. Internationalization and Character Encoding 911 All labels in GNS are encoded in UTF-8 [RFC3629]. This does not 912 include any DNS names found in DNS records, such as CNAME records, 913 which are internationalized through the IDNA specifications 914 [RFC5890]. 916 8. Name Resolution 918 Names in GNS are resolved by recursively querying the DHT record 919 storage. In the following, we define how resolution is initiated and 920 each iteration in the resolution is processed. 922 GNS resolution of a name must start in a given starting zone 923 indicated using a zone public key. Details on how the starting zone 924 may be determined is discussed in Section 10. 926 When GNS name resolution is requested, a desired record type MAY be 927 provided by the client. The GNS resolver will use the desired record 928 type to guide processing, for example by providing conversion of VPN 929 records to A or AAAA records, if that is desired. However, filtering 930 of record sets according to the required record types MUST still be 931 done by the client after the resource record set is retrieved. 933 8.1. Recursion 935 In each step of the recursive name resolution, there is an 936 authoritative zone zk and a name to resolve. The name may be empty. 937 Initially, the authoritative zone is the start zone. If the name is 938 empty, it is interpreted as the apex label "@". 940 From here, the following steps are recursively executed, in order: 942 1. Extract the right-most label from the name to look up. 944 2. Calculate q using the label and zk as defined in Section 6.1. 946 3. Perform a DHT query GET(q) to retrieve the RRBLOCK. 948 4. Verify and process the RRBLOCK and decrypt the BDATA contained in 949 it as defined in Section 6.3. 951 Upon receiving the RRBLOCK from the DHT, apart from verifying the 952 provided signature, the resolver MUST check that the authoritative 953 zone key was used to sign the record: The derived zone key "h*zk" 954 MUST match the public key provided in the RRBLOCK, otherwise the 955 RRBLOCK MUST be ignored and the DHT lookup GET(q) MUST continue. 957 8.2. Record Processing 959 Record processing occurs at the end of a single recursion. We assume 960 that the RRBLOCK has been cryptographically verified and decrypted. 961 At this point, we must first determine if we have received a valid 962 record set in the context of the name we are trying to resolve: 964 1. Case 1: If the remainder of the name to resolve is empty and the 965 record set does not consist of a delegation, CNAME or DNS2GNS 966 record, the record set is the result and the recursion is 967 concluded. 969 2. Case 2: If the name to be resolved is of the format 970 "_SERVICE._PROTO" and the record set contains one or more 971 matching BOX records, the records in the BOX records are the 972 result and the recusion is concluded (Section 8.2.4). 974 3. Case 3: If the remainder of the name to resolve is not empty and 975 does not match the "_SERVICE._PROTO" syntax, then the current 976 record set MUST consist of a single delegation record 977 (Section 8.2.1), a single CNAME record (Section 8.2.3), or one or 978 more GNS2DNS records (Section 8.2.2), which are processed as 979 described in the respective sections below. The record set may 980 include any number of supplemental records. Otherwise, 981 resolution fails and the resolver MUST return an empty record 982 set. Finally, after the recursion terminates, the client 983 preferences for the record type SHOULD be considered. If a VPN 984 record is found and the client requests an A or AAAA record, the 985 VPN record SHOULD be converted (Section 8.2.5) if possible. 987 8.2.1. Encountering zone delegation records 989 When the resolver encounters a record of a supported zone delegation 990 record type (such as PKEY or EDKEY) and the remainder of the name is 991 not empty, resolution continues recursively with the remainder of the 992 name in the GNS zone specified in the delegation record. 993 Implementations MUST NOT allow multiple different zone type 994 delegations under a single label. Implementations MAY support any 995 subset of zone types. If an unsupported zone type is encountered, 996 resolution fails (NXDOMAIN). 998 If the remainder of the name to resolve is empty and we have received 999 a record set containing only a single PKEY record, the recursion is 1000 continued with the PKEY as authoritative zone and the empty apex 1001 label "@" as remaining name, except in the case where the desired 1002 record type is PKEY, in which case the PKEY record is returned and 1003 the resolution is concluded without resolving the empty apex label. 1005 8.2.2. GNS2DNS 1007 When a resolver encounters one or more GNS2DNS records and the 1008 remaining name is empty and the desired record type is GNS2DNS, the 1009 GNS2DNS records are returned. 1011 Otherwise, it is expected that the resolver first resolves the IP(s) 1012 of the specified DNS name server(s). GNS2DNS records MAY contain 1013 numeric IPv4 or IPv6 addresses, allowing the resolver to skip this 1014 step. The DNS server names may themselves be names in GNS or DNS. 1015 If the DNS server name ends in ".+", the rest of the name is to be 1016 interpreted relative to the zone of the GNS2DNS record. If the DNS 1017 server name ends in a label representation of a zone key, the DNS 1018 server name is to be resolved against the GNS zone zk. 1020 Multiple GNS2DNS records may be stored under the same label, in which 1021 case the resolver MUST try all of them. The resolver MAY try them in 1022 any order or even in parallel. If multiple GNS2DNS records are 1023 present, the DNS name MUST be identical for all of them, if not the 1024 resolution fails and an emtpy record set is returned as the record 1025 set is invalid. 1027 Once the IP addresses of the DNS servers have been determined, the 1028 DNS name from the GNS2DNS record is appended to the remainder of the 1029 name to be resolved, and resolved by querying the DNS name server(s). 1030 As the DNS servers specified are possibly authoritative DNS servers, 1031 the GNS resolver MUST support recursive resolution and MUST NOT 1032 delegate this to the authoritative DNS servers. The first successful 1033 recursive name resolution result is returned to the client. In 1034 addition, the resolver returns the queried DNS name as a supplemental 1035 LEHO record (Section 5.4) with a relative expiration time of one 1036 hour. 1038 GNS resolvers SHOULD offer a configuration option to disable DNS 1039 processing to avoid information leakage and provide a consistent 1040 security profile for all name resolutions. Such resolvers would 1041 return an empty record set upon encountering a GNS2DNS record during 1042 the recursion. However, if GNS2DNS records are encountered in the 1043 record set for the apex and a GNS2DNS record is expicitly requested 1044 by the application, such records MUST still be returned, even if DNS 1045 support is disabled by the GNS resolver configuration. 1047 8.2.3. CNAME 1049 If a CNAME record is encountered, the canonical name is appended to 1050 the remaining name, except if the remaining name is empty and the 1051 desired record type is CNAME, in which case the resolution concludes 1052 with the CNAME record. If the canonical name ends in ".+", 1053 resolution continues in GNS with the new name in the current zone. 1054 Otherwise, the resulting name is resolved via the default operating 1055 system name resolution process. This may in turn again trigger a GNS 1056 resolution process depending on the system configuration. 1058 The recursive DNS resolution process may yield a CNAME as well which 1059 in turn may either point into the DNS or GNS namespace (if it ends in 1060 a label representation of a zone key). In order to prevent infinite 1061 loops, the resolver MUST implement loop detections or limit the 1062 number of recursive resolution steps. If the last CNAME was a DNS 1063 name, the resolver returns the DNS name as a supplemental LEHO record 1064 (Section 5.4) with a relative expiration time of one hour. 1066 8.2.4. BOX 1068 When a BOX record is received, a GNS resolver must unbox it if the 1069 name to be resolved continues with "_SERVICE._PROTO". Otherwise, the 1070 BOX record is to be left untouched. This way, TLSA (and SRV) records 1071 do not require a separate network request, and TLSA records become 1072 inseparable from the corresponding address records. 1074 8.2.5. VPN 1076 At the end of the recursion, if the queried record type is either A 1077 or AAAA and the retrieved record set contains at least one VPN 1078 record, the resolver SHOULD open a tunnel and return the IPv4 or IPv6 1079 tunnel address, respectively. The type of tunnel depends on the 1080 contents of the VPN record data. The VPN record MUST be returned if 1081 the resolver implementation does not support setting up a tunnnel. 1083 8.2.6. NICK 1085 NICK records are only relevant to the recursive resolver if the 1086 record set in question is the final result which is to be returned to 1087 the client. The encountered NICK records may either be supplemental 1088 (see Section 4) or non-supplemental. If the NICK record is 1089 supplemental, the resolver only returns the record set if one of the 1090 non-supplemental records matches the queried record type. 1092 The differentiation between a supplemental and non-supplemental NICK 1093 record allows the client to match the record to the authoritative 1094 zone. Consider the following example: 1096 Query: alice.example (type=A) 1097 Result: 1098 A: 192.0.2.1 1099 NICK: eve 1101 Figure 14 1103 In this example, the returned NICK record is non-supplemental. For 1104 the client, this means that the NICK belongs to the zone "alice.doe" 1105 and is published under the empty label along with an A record. The 1106 NICK record should be interpreted as: The zone defined by "alice.doe" 1107 wants to be referred to as "eve". In contrast, consider the 1108 following: 1110 Query: alice.example (type=AAAA) 1111 Result: 1112 AAAA: 2001:DB8::1 1113 NICK: john (Supplemental) 1115 Figure 15 1117 In this case, the NICK record is marked as supplemental. This means 1118 that the NICK record belongs to the zone "doe" and is published under 1119 the label "alice" along with an A record. The NICK record should be 1120 interpreted as: The zone defined by "doe" wants to be referred to as 1121 "john". This distinction is likely useful for other records 1122 published as supplemental. 1124 9. Zone Revocation 1126 Whenever a recursive resolver encounters a new GNS zone, it MUST 1127 check against the local revocation list whether the respective zone 1128 key has been revoked. If the zone key was revoked, the resolution 1129 MUST fail with an empty result set. 1131 In order to revoke a zone key, a signed revocation object SHOULD be 1132 published. This object MUST be signed using the private zone key. 1133 The revocation object is flooded in the overlay network. To prevent 1134 flooding attacks, the revocation message MUST contain a proof of work 1135 (PoW). The revocation message including the PoW MAY be calculated 1136 ahead of time to support timely revocation. 1138 For all occurences below, "Argon2id" is the Password-based Key 1139 Derivation Function as defined in [Argon2]. For the PoW calculations 1140 the algorithm is instantiated with the following parameters: 1142 S The salt. Fixed 16-octet string: "GnsRevocationPow". 1144 t Number of iterations: 3 1146 m Memory size in KiB: 1024 1148 T Output length of hash in bytes: 64 1150 p Parallelization parameter: 1 1152 v Algorithm version: 0x13 1154 y Algorithm type (Argon2id): 2 1156 X Unused 1158 K Unused 1160 The following is the message string "P" on which the PoW is 1161 calculated: 1163 0 8 16 24 32 40 48 56 1164 +-----+-----+-----+-----+-----+-----+-----+-----+ 1165 | POW | 1166 +-----------------------------------------------+ 1167 | TIMESTAMP | 1168 +-----------------------------------------------+ 1169 | ZONE TYPE | PUBLIC ZONE KEY | 1170 +-----+-----+-----+-----+ | 1171 / / 1172 / / 1173 +-----+-----+-----+-----+-----+-----+-----+-----+ 1175 Figure 16 1177 where: 1179 POW A 64-bit solution to the PoW. In network byte order. 1181 TIMESTAMP denotes the absolute 64-bit date when the revocation was 1182 computed. In microseconds since midnight (0 hour), January 1, 1183 1970 in network byte order. 1185 PUBLIC KEY is the 256-bit public key "zk" of the zone which is being 1186 revoked and the key to be used to verify SIGNATURE. The wire 1187 format of this value is defined in [RFC8032], Section 5.1.5. 1189 Traditionally, PoW schemes require to find a "POW" such that at least 1190 D leading zeroes are found in the hash result. D is then referred to 1191 as the "difficulty" of the PoW. In order to reduce the variance in 1192 time it takes to calculate the PoW, we require that a number "Z" 1193 different PoWs must be found that on average have "D" leading zeroes. 1195 The resulting proofs may then published and disseminated. The 1196 concrete dissemination and publication methods are out of scope of 1197 this document. Given an average difficulty of "D", the proofs have 1198 an expiration time of EPOCH. With each additional bit difficulty, 1199 the lifetime of the proof is prolonged for another EPOCH. 1200 Consequently, by calculating a more difficult PoW, the lifetime of 1201 the proof can be increased on demand by the zone owner. 1203 The parameters are defined as follows: 1205 Z The number of PoWs required is fixed at 32. 1207 D The difficulty is fixed at 22. 1209 EPOCH A single epoch is fixed at 365 days. 1211 Given that proof has been found, a revocation data object is defined 1212 as follows: 1214 0 8 16 24 32 40 48 56 1215 +-----+-----+-----+-----+-----+-----+-----+-----+ 1216 | TIMESTAMP | 1217 +-----+-----+-----+-----+-----+-----+-----+-----+ 1218 | TTL | 1219 +-----+-----+-----+-----+-----+-----+-----+-----+ 1220 | POW_0 | 1221 +-----+-----+-----+-----+-----+-----+-----+-----+ 1222 | ... | 1223 +-----+-----+-----+-----+-----+-----+-----+-----+ 1224 | POW_Z-1 | 1225 +-----------------------------------------------+ 1226 | ZONE TYPE | PUBLIC ZONE KEY | 1227 +-----+-----+-----+-----+ | 1228 / / 1229 / / 1230 +-----+-----+-----+-----+-----+-----+-----+-----+ 1231 | SIGNATURE | 1232 / / 1233 / / 1234 | | 1235 +-----+-----+-----+-----+-----+-----+-----+-----+ 1237 Figure 17 1239 where: 1241 TIMESTAMP denotes the absolute 64-bit date when the revocation was 1242 computed. In microseconds since midnight (0 hour), January 1, 1243 1970 in network byte order. This is the same value as the 1244 timestamp used in the individual PoW calculations. 1246 TTL denotes the relative 64-bit time to live of of the record in 1247 microseconds also in network byte order. This field is 1248 informational for a verifier. The verifier may discard revocation 1249 if the TTL indicates that it is already expired. However, the 1250 actual TTL of the revocation must be determined by examining the 1251 leading zeros in the proof of work calculation. 1253 POW_i The values calculated as part of the PoW, in network byte 1254 order. Each POW_i MUST be unique in the set of POW values. To 1255 facilitate fast verification of uniqueness, the POW values must be 1256 given in strictly monotonically increasing order in the message. 1258 ZONE TYPE The 32-bit zone type corresponding to the zone public key. 1260 ZONE PUBLIC KEY is the public key "zk" of the zone which is being 1261 revoked and the key to be used to verify SIGNATURE. 1263 SIGNATURE A signature over a timestamp and the public zone zk of the 1264 zone which is revoked and corresponds to the key used in the PoW. 1265 The signature is created using the Sign() function of the 1266 cryptosystem of the zone and the private zone key (see Section 3). 1268 The signature over the public key covers a 32-bit pseudo header 1269 conceptually prefixed to the public key. The pseudo header includes 1270 the key length and signature purpose: 1272 0 8 16 24 32 40 48 56 1273 +-----+-----+-----+-----+-----+-----+-----+-----+ 1274 | SIZE (0x30) | PURPOSE (0x03) | 1275 +-----+-----+-----+-----+-----+-----+-----+-----+ 1276 | ZONE TYPE | ZONE PUBLIC KEY | 1277 +-----+-----+-----+-----+ | 1278 / / 1279 / / 1280 +-----+-----+-----+-----+-----+-----+-----+-----+ 1281 | TIMESTAMP | 1282 +-----+-----+-----+-----+-----+-----+-----+-----+ 1284 Figure 18 1286 where: 1288 SIZE A 32-bit value containing the length of the signed data in 1289 bytes in network byte order. 1291 PURPOSE A 32-bit signature purpose flag. This field MUST be 3 (in 1292 network byte order). 1294 ZONE TYPE The 32-bit zone type corresponding to the zone public key. 1296 ZONE PUBLIC KEY / TIMESTAMP Both values as defined in the revocation 1297 data object above. 1299 In order to verify a revocation the following steps must be taken, in 1300 order: 1302 1. The current time MUST be between TIMESTAMP and TIMESTAMP+TTL. 1304 2. The signature MUST match the public key. 1306 3. The set of POW values MUST NOT contain duplicates. 1308 4. The average number of leading zeroes resulting from the provided 1309 POW values D' MUST be greater than D. 1311 5. The validation period (TTL) of the revocation is calculated as 1312 (D'-D) * EPOCH * 1.1. The EPOCH is extended by 10% in order to 1313 deal with unsynchronized clocks. The TTL added on top of the 1314 TIMESTAMP yields the expiration date. 1316 10. Determining the Root Zone and Zone Governance 1318 The resolution of a GNS name must start in a given start zone 1319 indicated to the resolver using any public zone key. The local 1320 resolver may have a local start zone configured/hard-coded which 1321 points to a local or remote start zone key. A resolver client may 1322 also determine the start zone from the suffix of the name given for 1323 resolution or using information retrieved out of band. The 1324 governance model of any zone is at the sole discretion of the zone 1325 owner. However, the choice of start zone(s) is at the sole 1326 discretion of the local system administrator or user. 1328 This is an important distinguishing factor from the Domain Name 1329 System where root zone governance is centralized at the Internet 1330 Corporation for Assigned Names and Numbers (ICANN). In DNS 1331 terminology, GNS roughly follows the idea of a hyper-hyper local root 1332 zone deployment, with the difference that it is not expected that all 1333 deployments use the same local root zone. 1335 In the following, we give examples how a local client resolver SHOULD 1336 discover the start zone. The process given is not exhaustive and 1337 clients MAY suppliement it with other mechanisms or ignore it if the 1338 particular application requires a different process. 1340 GNS clients MUST first try to interpret the top-level domain of a GNS 1341 name as a zone key representation ("zTLD"). If the top-level domain 1342 is indicated to be a label representation of a public zone key with a 1343 well-defined "ztype" value, the root zone of the resolution process 1344 is implicitly given by the suffic of the name: 1346 Example name: www.example. 1347 => Root zone: zk of type ztype 1348 => Name to resolve from root zone: www.example 1350 In GNS, users MAY own and manage their own zones. Each local zone 1351 SHOULD be associated with a single GNS label, but users MAY choose to 1352 use longer names consisting of multiple labels. If the name of a 1353 locally managed zone matches the suffix of the name to be resolved, 1354 resolution SHOULD start from the respective local zone: 1356 Example name: www.example.org 1357 Local zones: 1358 fr = (d0,zk0) 1359 gnu = (d1,zk1) 1360 com = (d2,zk2) 1361 ... 1362 => Entry zone: zk1 1363 => Name to resolve from entry zone: www.example 1365 Finally, additional "suffix to zone" mappings MAY be configured. 1366 Suffix to zone key mappings SHOULD be configurable through a local 1367 configuration file or database by the user or system administrator. 1368 The suffix MAY consist of multiple GNS labels concatenated with a 1369 ".". If multiple suffixes match the name to resolve, the longest 1370 matching suffix MUST BE used. The suffix length of two results 1371 cannot be equal, as this would indicate a misconfiguration. If both 1372 a locally managed zone and a configuration entry exist for the same 1373 suffix, the locally managed zone MUST have priority. 1375 Example name: www.example.org 1376 Local suffix mappings: 1377 gnu = zk0 1378 example.org = zk1 1379 example.com = zk2 1380 ... 1381 => Entry zone: zk1 1382 => Name to resolve from entry zone: www 1384 11. Security Considerations 1386 11.1. Cryptography 1388 The security of cryptographic systems depends on both the strength of 1389 the cryptographic algorithms chosen and the strength of the keys used 1390 with those algorithms. The security also depends on the engineering 1391 of the protocol used by the system to ensure that there are no non- 1392 cryptographic ways to bypass the security of the overall system. 1394 This document concerns itself with the selection of cryptographic 1395 algorithms for use in GNS. The algorithms identified in this 1396 document are not known to be broken (in the cryptographic sense) at 1397 the current time, and cryptographic research so far leads us to 1398 believe that they are likely to remain secure into the foreseeable 1399 future. However, this isn't necessarily forever, and it is expected 1400 that new revisions of this document will be issued from time to time 1401 to reflect the current best practices in this area. 1403 GNS PKEY zone keys use ECDSA over Curve25519. This is an 1404 unconventional choice, as ECDSA is usually used with other curves. 1405 However, traditional ECDSA curves are problematic for a range of 1406 reasons described in the Curve25519 and EdDSA papers. Using EdDSA 1407 directly is also not possible, as a hash function is used on the 1408 private key which destroys the linearity that the GNU Name System 1409 depends upon. We are not aware of anyone suggesting that using 1410 Curve25519 instead of another common curve of similar size would 1411 lower the security of ECDSA. GNS uses 256-bit curves because that 1412 way the encoded (public) keys fit into a single DNS label, which is 1413 good for usability. 1415 In terms of crypto-agility, whenever the need for an updated 1416 cryptographic scheme arises to, for example, replace ECDSA over 1417 Curve25519 for PKEY records it may simply be introduced through a new 1418 record type. Such a new record type may then replace the delegation 1419 record type for future records. The old record type remains and 1420 zones can iteratively migrate to the updated zone keys. 1422 In order to ensure ciphertext indistinguishability, care must be 1423 taken with respect to the initialization vector in the counter block. 1424 In our design, the IV is always the expiration time of the record 1425 block. For blocks with relative expiration times it is implicitly 1426 ensured that each time a block is published into the DHT, its IV is 1427 unique as the expiration time is calculated dynamically and increases 1428 monotonically. For blocks with absolute expiration times, the 1429 implementation MUST ensure that the expiration time is modified when 1430 the record data changes. For example. the expiration time may be 1431 increased by a single microsecond. 1433 11.2. Abuse mitigation 1435 GNS names are UTF-8 strings. Consequently, GNS faces similar issues 1436 with respect to name spoofing as DNS does for internationalized 1437 domain names. In DNS, attackers may register similar sounding or 1438 looking names (see above) in order to execute phishing attacks. GNS 1439 zone administrators must take into account this attack vector and 1440 incorporate rules in order to mitigate it. 1442 Further, DNS can be used to combat illegal content on the internet by 1443 having the respective domains seized by authorities. However, the 1444 same mechanisms can also be abused in order to impose state 1445 censorship, which ist one of the motivations behind GNS. Hence, such 1446 a seizure is, by design, difficult to impossible in GNS. In 1447 particular, GNS does not support WHOIS ([RFC3912]). 1449 11.3. Zone management 1451 In GNS, zone administrators need to manage and protect their zone 1452 keys. Once a zone key is lost it cannot be recovered. Once it is 1453 compromised it cannot be revoked (unless a revocation message was 1454 pre-calculated and is still available). Zone administrators, and for 1455 GNS this includes end-users, are required to responsibly and 1456 dilligently protect their cryptographic keys. Offline signing is in 1457 principle possible, but GNS does not support separate zone signing 1458 and key-signing keys (as in [RFC6781]) in order to provide usable 1459 security. 1461 Similarly, users are required to manage their local root zone. In 1462 order to ensure integrity and availability or names, users must 1463 ensure that their local root zone information is not compromised or 1464 outdated. It can be expected that the processing of zone revocations 1465 and an initial root zone is provided with a GNS client implementation 1466 ("drop shipping"). Extension and customization of the zone is at the 1467 full discretion of the user. 1469 11.4. Impact of underlying DHT 1471 This document does not specifiy the properties of the underlying 1472 distributed hash table (DHT) which is required by any GNS 1473 implementation. For implementors, it is important to note that the 1474 properties of the DHT are directly inherited by the GNS 1475 implementation. This includes both security as well as other non- 1476 functional properties such as scalability and performance. 1477 Implementors should take great care when selecting or implementing a 1478 DHT for use in a GNS implementation. DHTs with strong security and 1479 performance guarantees exist [R5N]. It should also be taken into 1480 consideration that GNS implementations which build upon different DHT 1481 overlays are unlikely to be interoperable with each other. 1483 11.5. Revocations 1485 Zone administrators are advised to pre-generate zone revocations and 1486 securely store the revocation information in case the zone key is 1487 lost, compromised or replaced in the furture. Pre-calculated 1488 revocations may become invalid due to expirations or protocol changes 1489 such as epoch adjustments. Consequently, implementors and users must 1490 make precautions in order to manage revocations accordingly. 1492 Revocation payloads do NOT include a 'new' key for key replacement. 1493 Inclusion of such a key would have two major disadvantages: 1495 If revocation is used after a private key was compromised, allowing 1496 key replacement would be dangerous: if an adversary took over the 1497 private key, the adversary could then broadcast a revocation with a 1498 key replacement. For the replacement, the compromised owner would 1499 have no chance to issue even a revocation. Thus, allowing a 1500 revocation message to replace a private key makes dealing with key 1501 compromise situations worse. 1503 Sometimes, key revocations are used with the objective of changing 1504 cryptosystems. Migration to another cryptosystem by replacing keys 1505 via a revocation message would only be secure as long as both 1506 cryptosystems are still secure against forgery. Such a planned, non- 1507 emergency migration to another cryptosystem should be done by running 1508 zones for both ciphersystems in parallel for a while. The migration 1509 would conclude by revoking the legacy zone key only once it is deemed 1510 no longer secure, and hopefully after most users have migrated to the 1511 replacement. 1513 12. GANA Considerations 1515 GANA [GANA] is requested to create an "GNU Name System Record Types" 1516 registry. The registry shall record for each entry: 1518 * Name: The name of the record type (case-insensitive ASCII string, 1519 restricted to alphanumeric characters 1521 * Number: 32-bit, above 65535 1523 * Comment: Optionally, a brief English text describing the purpose 1524 of the record type (in UTF-8) 1526 * Contact: Optionally, the contact information of a person to 1527 contact for further information 1529 * References: Optionally, references describing the record type 1530 (such as an RFC) 1532 The registration policy for this sub-registry is "First Come First 1533 Served", as described in [RFC8126]. GANA is requested to populate 1534 this registry as follows: 1536 Number | Name | Contact | References | Description 1537 -------+---------+---------+------------+------------------------- 1538 65536 | PKEY | N/A | [This.I-D] | GNS zone delegation 1539 65537 | NICK | N/A | [This.I-D] | GNS zone nickname 1540 65538 | LEHO | N/A | [This.I-D] | GNS legacy hostname 1541 65539 | VPN | N/A | [This.I-D] | VPN resolution 1542 65540 | GNS2DNS | N/A | [This.I-D] | Delegation to DNS 1543 65541 | BOX | N/A | [This.I-D] | Boxed record 1545 Figure 19 1547 GANA is requested to amend the "GNUnet Signature Purpose" registry as 1548 follows: 1550 Purpose | Name | References | Description 1551 --------+-----------------+------------+-------------------------- 1552 3 | GNS_REVOCATION | [This.I-D] | GNS zone key revocation 1553 15 | GNS_RECORD_SIGN | [This.I-D] | GNS record set signature 1555 Figure 20 1557 13. Test Vectors 1559 The following represents a test vector for a record set with a DNS 1560 record of type "A" as well as a GNS record of type "PKEY" under the 1561 label "test". 1563 Zone private key (d, little-endian, with ztype prepended): 1564 0001000020110ab2 1565 807d702f7b86dc30 1566 6c37e8e2e0a5dbb2 1567 7ae934727d9ca07d 1568 69c73579 1570 Zone identifier (zid): 1571 0001000063db8bf0 1572 44212617ce5db4fc 1573 7c06fb9e35b2e177 1574 3b4b76c05b42a1e7 1575 17d018c6 1577 Encoded zone identifier (zkl = zTLD): 1578 000G0033VE5Z0H114RBWWQDMZHY0DYWY6PSE2XSV9DVC0PT2M7KHFM0RRR 1580 Label: test 1581 RRCOUNT: 2 1582 Record #0 1583 EXPIRATION: 1602865000130231 1584 DATA_SIZE: 4 1585 TYPE: 1 1586 FLAGS: 0 1587 DATA: 1588 01020304 1590 Record #1 1591 EXPIRATION: 1602865000130231 1592 DATA_SIZE: 32 1593 TYPE: 65536 1594 FLAGS: 2 1595 DATA: 1596 00010000796f4a8b 1597 66d7780f62f46604 1598 24c750295f31674d 1599 052a4989cf0779a7 1601 RDATA: 1602 0005b1cc16f4a6b7 1603 0000000400000001 1604 0000000001020304 1605 0005b1cc16f4a6b7 1606 0000002000010000 1607 0000000200010000 1608 796f4a8b66d7780f 1609 62f4660424c75029 1610 5f31674d052a4989 1611 cf0779a700000000 1612 0000000000000000 1613 0000000000000000 1614 0000000000000000 1615 0000000000000000 1616 0000000000000000 1617 0000000000000000 1619 BDATA: 1620 4f20986bde1fbbed 1621 b57196c1c23e35e9 1622 f1ee62207de81297 1623 0c2b370a9980042f 1624 e8296cdd8ca66d69 1625 11ebb2f3b2550959 1626 7cb781ef56ac07d1 1627 7c5dd0903bb94c67 1628 c07e100079f59db3 1629 3363fe110f435838 1630 ef482e60b527f553 1631 2ee435e4c0525439 1632 3965d3dbe72e7c92 1633 9bb4172b3bda7270 1634 06c33578682cb212 1635 23ac2cf389a4fbab 1636 bb8cb55e 1638 RRBLOCK: 1639 000100007bc2eb40 1640 ef056b05a5a84c35 1641 241ca7190284a4a4 1642 f5afdae14e8b784c 1643 4b516dd6082d7969 1644 2d2bbcb1328bc1df 1645 270b2c02693bdaa9 1646 f4d496dd850068d4 1647 3a471fac0156b902 1648 3536e54960fac47b 1649 58762d82c5ad8e7f 1650 34a121819c7ca75d 1651 64c78d3a00000094 1652 0000000f0005b1cc 1653 16f4a6b74f20986b 1654 de1fbbedb57196c1 1655 c23e35e9f1ee6220 1656 7de812970c2b370a 1657 9980042fe8296cdd 1658 8ca66d6911ebb2f3 1659 b25509597cb781ef 1660 56ac07d17c5dd090 1661 3bb94c67c07e1000 1662 79f59db33363fe11 1663 0f435838ef482e60 1664 b527f5532ee435e4 1665 c05254393965d3db 1666 e72e7c929bb4172b 1667 3bda727006c33578 1668 682cb21223ac2cf3 1669 89a4fbabbb8cb55e 1671 The following is an example revocation for a zone: 1673 Zone private key (d, little-endian scalar, with ztype prepended): 1674 00010000a065bf68 1675 07cb3d90d10394a9 1676 a56693e07087ad35 1677 24f8e303931d4ade 1678 946dc447 1680 Zone identifier (zid): 1681 00010000d06ab6d9 1682 14e8a8064609b2b3 1683 cb661c586042adcb 1684 0dc5faeb61994d25 1685 5ebdca72 1687 Encoded zone identifier (zkl = zTLD): 1688 000G006GDAVDJ578N034C2DJPF5PC72RC11AVJRDRQXEPRCS9MJNXFEAE8 1690 Difficulty (5 base difficulty + 2 epochs): 7 1692 Proof: 1693 0005b13f536e2b0e 1694 0000395d1827c000 1695 5caaeaa2b955d82c 1696 5caaeaa2b955da02 1697 5caaeaa2b955daf0 1698 5caaeaa2b955db20 1699 5caaeaa2b955db2d 1700 5caaeaa2b955dba1 1701 5caaeaa2b955dba9 1702 5caaeaa2b955dbc2 1703 5caaeaa2b955dbc8 1704 5caaeaa2b955dbd1 1705 5caaeaa2b955dbf7 1706 5caaeaa2b955dc0e 1707 5caaeaa2b955dc54 1708 5caaeaa2b955dc8c 1709 5caaeaa2b955dca5 1710 5caaeaa2b955dcb5 1711 5caaeaa2b955dcf8 1712 5caaeaa2b955dd47 1713 5caaeaa2b955dd91 1714 5caaeaa2b955dd98 1715 5caaeaa2b955dd99 1716 5caaeaa2b955ddc4 1717 5caaeaa2b955de7f 1718 5caaeaa2b955de80 1719 5caaeaa2b955de92 1720 5caaeaa2b955ded3 1721 5caaeaa2b955df1a 1722 5caaeaa2b955df77 1723 5caaeaa2b955dfdf 1724 5caaeaa2b955e06e 1725 5caaeaa2b955e08d 1726 5caaeaa2b955e0c4 1727 00010000d06ab6d9 1728 14e8a8064609b2b3 1729 cb661c586042adcb 1730 0dc5faeb61994d25 1731 5ebdca7206b11f93 1732 41f4e1649976c421 1733 b1efe668a44becbe 1734 5a9f76804adb6f6e 1735 2cd16de00d81841d 1736 cbd135aacad3bdab 1737 3f2209bd10d55cc1 1738 c7aed9a9bd53a1f6 1739 cae1789d 1741 14. Normative References 1743 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1744 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1745 . 1747 [RFC1035] Mockapetris, P., "Domain names - implementation and 1748 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1749 November 1987, . 1751 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1752 specifying the location of services (DNS SRV)", RFC 2782, 1753 DOI 10.17487/RFC2782, February 2000, 1754 . 1756 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1757 Requirement Levels", BCP 14, RFC 2119, 1758 DOI 10.17487/RFC2119, March 1997, 1759 . 1761 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1762 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1763 2003, . 1765 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 1766 Counter Mode With IPsec Encapsulating Security Payload 1767 (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, 1768 . 1770 [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The 1771 Advanced Encryption Standard (AES) Cipher Algorithm in the 1772 SNMP User-based Security Model", RFC 3826, 1773 DOI 10.17487/RFC3826, June 2004, 1774 . 1776 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 1777 DOI 10.17487/RFC3912, September 2004, 1778 . 1780 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1781 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1782 . 1784 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1785 Key Derivation Function (HKDF)", RFC 5869, 1786 DOI 10.17487/RFC5869, May 2010, 1787 . 1789 [RFC5890] Klensin, J., "Internationalized Domain Names for 1790 Applications (IDNA): Definitions and Document Framework", 1791 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1792 . 1794 [RFC5891] Klensin, J., "Internationalized Domain Names in 1795 Applications (IDNA): Protocol", RFC 5891, 1796 DOI 10.17487/RFC5891, August 2010, 1797 . 1799 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 1800 Operational Practices, Version 2", RFC 6781, 1801 DOI 10.17487/RFC6781, December 2012, 1802 . 1804 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 1805 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 1806 April 2013, . 1808 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 1809 Algorithm (DSA) and Elliptic Curve Digital Signature 1810 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 1811 2013, . 1813 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1814 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1815 2016, . 1817 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1818 Signature Algorithm (EdDSA)", RFC 8032, 1819 DOI 10.17487/RFC8032, January 2017, 1820 . 1822 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1823 Writing an IANA Considerations Section in RFCs", BCP 26, 1824 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1825 . 1827 [GANA] GNUnet e.V., "GNUnet Assigned Numbers Authority (GANA)", 1828 April 2020, . 1830 [GNS] Wachs, M., Schanzenbach, M., and C. Grothoff, "A 1831 Censorship-Resistant, Privacy-Enhancing and Fully 1832 Decentralized Name System", 2014, 1833 . 1835 [R5N] Evans, N. S. and C. Grothoff, "R5N: Randomized recursive 1836 routing for restricted-route networks", 2011, 1837 . 1839 [Argon2] Biryukov, A., Dinu, D., Khovratovich, D., and S. 1840 Josefsson, "The memory-hard Argon2 password hash and 1841 proof-of-work function", March 2020, 1842 . 1845 [MODES] Dworkin, M., "Recommendation for Block Cipher Modes of 1846 Operation: Methods and Techniques", December 2001, 1847 . 1849 [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of 1850 Operation: Galois/Counter Mode (GCM) and GMAC", November 1851 2007, . 1853 [CrockfordB32] 1854 Douglas, D., "Base32", March 2019, 1855 . 1857 [Tor224] Goulet, D., Kadianakis, G., and N. Mathewson, "Next- 1858 Generation Hidden Services in Tor", November 2013, 1859 . 1862 [ed25519] Bernstein, D., Duif, N., Lange, T., Schwabe, P., and B. 1863 Yang, "High-Speed High-Security Signatures", 2011, 1864 . 1867 Authors' Addresses 1869 Martin Schanzenbach 1870 GNUnet e.V. 1871 Boltzmannstrasse 3 1872 85748 Garching 1873 Germany 1875 Email: schanzen@gnunet.org 1877 Christian Grothoff 1878 Berner Fachhochschule 1879 Hoeheweg 80 1880 CH-2501 Biel/Bienne 1881 Switzerland 1883 Email: grothoff@gnunet.org 1885 Bernd Fix 1886 GNUnet e.V. 1887 Boltzmannstrasse 3 1888 85748 Garching 1889 Germany 1891 Email: fix@gnunet.org