idnits 2.17.1 draft-schanzen-gns-01.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 152 has weird spacing: '... zk is the ...' == Line 463 has weird spacing: '... label is a ...' -- The document date (6 July 2020) is 1383 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: 7 January 2021 Berner Fachhochschule 6 B. Fix 7 GNUnet e.V. 8 6 July 2020 10 The GNU Name System 11 draft-schanzen-gns-01 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 7 January 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. Resource Records . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. Record Types . . . . . . . . . . . . . . . . . . . . . . 6 55 3.2. PKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.3. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.4. LEHO . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 3.5. NICK . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 3.6. BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.7. VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 4. Publishing Records . . . . . . . . . . . . . . . . . . . . . 10 62 4.1. Key Derivations . . . . . . . . . . . . . . . . . . . . . 10 63 4.2. Resource Records Block . . . . . . . . . . . . . . . . . 11 64 4.3. Record Data Encryption and Decryption . . . . . . . . . . 13 65 5. Internationalization and Character Encoding . . . . . . . . . 15 66 6. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 15 67 6.1. Recursion . . . . . . . . . . . . . . . . . . . . . . . . 16 68 6.2. Record Processing . . . . . . . . . . . . . . . . . . . . 16 69 6.2.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . 17 70 6.2.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 17 71 6.2.3. CNAME . . . . . . . . . . . . . . . . . . . . . . . . 18 72 6.2.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 6.2.5. VPN . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 6.2.6. NICK . . . . . . . . . . . . . . . . . . . . . . . . 19 75 7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 20 76 8. Determining the Root Zone and Zone Governance . . . . . . . . 24 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 78 9.1. Cryptography . . . . . . . . . . . . . . . . . . . . . . 25 79 9.2. Abuse mitigation . . . . . . . . . . . . . . . . . . . . 26 80 9.3. Zone management . . . . . . . . . . . . . . . . . . . . . 26 81 9.4. Impact of underlying DHT . . . . . . . . . . . . . . . . 27 82 9.5. Revocations . . . . . . . . . . . . . . . . . . . . . . . 27 83 10. GANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 84 11. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 29 85 12. Normative References . . . . . . . . . . . . . . . . . . . . 32 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 88 1. Introduction 90 The Domain Name System (DNS) is a unique distributed database and a 91 vital service for most Internet applications. While DNS is 92 distributed, it relies on centralized, trusted registrars to provide 93 globally unique names. As the awareness of the central role DNS 94 plays on the Internet rises, various institutions are using their 95 power (including legal means) to engage in attacks on the DNS, thus 96 threatening the global availability and integrity of information on 97 the Internet. 99 DNS was not designed with security as a goal. This makes it very 100 vulnerable, especially to attackers that have the technical 101 capabilities of an entire nation state at their disposal. This 102 specification describes a censorship-resistant, privacy-preserving 103 and decentralized name system: The GNU Name System (GNS). It is 104 designed to provide a secure alternative to DNS, especially when 105 censorship or manipulation is encountered. GNS can bind names to any 106 kind of cryptographically secured token, enabling it to double in 107 some respects as even as an alternative to some of today's Public Key 108 Infrastructures, in particular X.509 for the Web. 110 This document contains the GNU Name System (GNS) technical 111 specification of the GNU Name System [GNS], a fully decentralized and 112 censorship-resistant name system. GNS provides a privacy-enhancing 113 alternative to the Domain Name System (DNS). The design of GNS 114 incorporates the capability to integrate and coexist with DNS. GNS 115 is based on the principle of a petname system and builds on ideas 116 from the Simple Distributed Security Infrastructure (SDSI), 117 addressing a central issue with the decentralized mapping of secure 118 identifiers to memorable names: namely the impossibility of providing 119 a global, secure and memorable mapping without a trusted authority. 120 GNS uses the transitivity in the SDSI design to replace the trusted 121 root with secure delegation of authority thus making petnames useful 122 to other users while operating under a very strong adversary model. 124 This document defines the normative wire format of resource records, 125 resolution processes, cryptographic routines and security 126 considerations for use by implementors. 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 2. Zones 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. GNS 136 employs the curve parameters of the twisted edwards representation of 137 Curve25519 [RFC7748] (a.k.a. edwards25519) with the ECDSA scheme 138 ([RFC6979]). In the following, we use the following naming 139 convention for our cryptographic primitives: 141 d is a 256-bit ECDSA private key. In GNS, records are signed using 142 a key derived from "d" as described in Section 4. 144 p is the prime of edwards25519 as defined in [RFC7748], i.e. 2^255 145 - 19. 147 B is the group generator (X(P),Y(P)) of edwards25519 as defined in 148 [RFC7748]. 150 L is the prime-order subgroup of edwards25519 in [RFC7748]. 152 zk is the ECDSA public key corresponding to d. It is defined in 153 [RFC6979] as the curve point d*B where B is the group generator of 154 the elliptic curve. The public key is used to uniquely identify a 155 GNS zone and is referred to as the "zone key". 157 3. Resource Records 159 A GNS implementor MUST provide a mechanism to create and manage 160 resource records for local zones. A local zone is established by 161 creating a zone key pair. Records may be added to each zone, hence a 162 (local) persistency mechanism for resource records and zones must be 163 provided. This local zone database is used by the GNS resolver 164 implementation and to publish record information. 166 A GNS resource record holds the data of a specific record in a zone. 167 The resource record format is defined as follows: 169 0 8 16 24 32 40 48 56 170 +-----+-----+-----+-----+-----+-----+-----+-----+ 171 | EXPIRATION | 172 +-----+-----+-----+-----+-----+-----+-----+-----+ 173 | DATA SIZE | TYPE | 174 +-----+-----+-----+-----+-----+-----+-----+-----+ 175 | FLAGS | DATA / 176 +-----+-----+-----+-----+ / 177 / / 178 / / 179 Figure 1 181 where: 183 EXPIRATION denotes the absolute 64-bit expiration date of the 184 record. In microseconds since midnight (0 hour), January 1, 1970 185 in network byte order. 187 DATA SIZE denotes the 32-bit size of the DATA field in bytes and in 188 network byte order. 190 TYPE is the 32-bit resource record type. This type can be one of 191 the GNS resource records as defined in Section 3 or a DNS record 192 type as defined in [RFC1035] or any of the complementary 193 standardized DNS resource record types. This value must be stored 194 in network byte order. Note that values below 2^16 are reserved 195 for allocation via IANA ([RFC6895]). 197 FLAGS is a 32-bit resource record flags field (see below). 199 DATA the variable-length resource record data payload. The contents 200 are defined by the respective type of the resource record. 202 Flags indicate metadata surrounding the resource record. A flag 203 value of 0 indicates that all flags are unset. The following 204 illustrates the flag distribution in the 32-bit flag value of a 205 resource record: 207 ... 5 4 3 2 1 0 208 ------+--------+--------+--------+--------+--------+ 209 / ... | SHADOW | EXPREL | SUPPL | PRIVATE| / | 210 ------+--------+--------+--------+--------+--------+ 212 Figure 2 214 where: 216 SHADOW If this flag is set, this record should be ignored by 217 resolvers unless all (other) records of the same record type have 218 expired. Used to allow zone publishers to facilitate good 219 performance when records change by allowing them to put future 220 values of records into the DHT. This way, future values can 221 propagate and may be cached before the transition becomes active. 223 EXPREL The expiration time value of the record is a relative time 224 (still in microseconds) and not an absolute time. This flag 225 should never be encountered by a resolver for records obtained 226 from the DHT, but might be present when a resolver looks up 227 private records of a zone hosted locally. 229 SUPPL This is a supplemental record. It is provided in addition to 230 the other records. This flag indicates that this record is not 231 explicitly managed alongside the other records under the 232 respective name but may be useful for the application. This flag 233 should only be encountered by a resolver for records obtained from 234 the DHT. 236 PRIVATE This is a private record of this peer and it should thus not 237 be published in the DHT. Thus, this flag should never be 238 encountered by a resolver for records obtained from the DHT. 239 Private records should still be considered just like regular 240 records when resolving labels in local zones. 242 3.1. Record Types 244 A registry of GNS Record Types is described in Section 10. The 245 registration policy for this registry is "First Come First Served", 246 as described in [RFC8126]. When requesting new entries, careful 247 consideration of the following criteria is strongly advised: FIXME: 248 ausdenken was wir da gerne haetten. 250 3.2. PKEY 252 In GNS, a delegation of a label to a zone is represented through a 253 PKEY record. A PKEY resource record contains the public key of the 254 zone to delegate to. A PKEY record MUST be the only record under a 255 label. No other records are allowed. A PKEY DATA entry has the 256 following format: 258 0 8 16 24 32 40 48 56 259 +-----+-----+-----+-----+-----+-----+-----+-----+ 260 | PUBLIC KEY | 261 | | 262 | | 263 | | 264 +-----+-----+-----+-----+-----+-----+-----+-----+ 266 Figure 3 268 where: 270 PUBLIC KEY A 256-bit ECDSA zone key. 272 3.3. GNS2DNS 274 It is possible to delegate a label back into DNS through a GNS2DNS 275 record. The resource record contains a DNS name for the resolver to 276 continue with in DNS followed by a DNS server. Both names are in the 277 format defined in [RFC1034] for DNS names. A GNS2DNS DATA entry has 278 the following format: 280 0 8 16 24 32 40 48 56 281 +-----+-----+-----+-----+-----+-----+-----+-----+ 282 | DNS NAME | 283 / / 284 / / 285 | | 286 +-----+-----+-----+-----+-----+-----+-----+-----+ 287 | DNS SERVER NAME | 288 / / 289 / / 290 | | 291 +-----------------------------------------------+ 293 Figure 4 295 where: 297 DNS NAME The name to continue with in DNS (0-terminated). 299 DNS SERVER NAME The DNS server to use. May be an IPv4/IPv6 address 300 in dotted decimal form or a DNS name. It may also be a relative 301 GNS name ending with a "+" top-level domain. The value is UTF-8 302 encoded (also for DNS names) and 0-terminated. 304 3.4. LEHO 306 Legacy hostname records can be used by applications that are expected 307 to supply a DNS name on the application layer. The most common use 308 case is HTTP virtual hosting, which as-is would not work with GNS 309 names as those may not be globally unique. A LEHO resource record is 310 expected to be found together in a single resource record with an 311 IPv4 or IPv6 address. A LEHO DATA entry has the following format: 313 0 8 16 24 32 40 48 56 314 +-----+-----+-----+-----+-----+-----+-----+-----+ 315 | LEGACY HOSTNAME | 316 / / 317 / / 318 | | 319 +-----+-----+-----+-----+-----+-----+-----+-----+ 320 Figure 5 322 where: 324 LEGACY HOSTNAME A UTF-8 string (which is not 0-terminated) 325 representing the legacy hostname. 327 NOTE: If an application uses a LEHO value in an HTTP request header 328 (e.g. "Host:" header) it must be converted to a punycode 329 representation [RFC5891]. 331 3.5. NICK 333 Nickname records can be used by zone administrators to publish an 334 indication on what label this zone prefers to be referred to. This 335 is a suggestion to other zones what label to use when creating a PKEY 336 (Section 3.2) record containing this zone's public zone key. This 337 record SHOULD only be stored under the empty label "@" but MAY be 338 returned with record sets under any label as a supplemental record. 339 Section 6.2.6 details how a resolver must process supplemental and 340 non-supplemental NICK records. A NICK DATA entry has the following 341 format: 343 0 8 16 24 32 40 48 56 344 +-----+-----+-----+-----+-----+-----+-----+-----+ 345 | NICKNAME | 346 / / 347 / / 348 | | 349 +-----+-----+-----+-----+-----+-----+-----+-----+ 351 Figure 6 353 where: 355 NICKNAME A UTF-8 string (which is not 0-terminated) representing the 356 preferred label of the zone. This string MUST NOT include a "." 357 character. 359 3.6. BOX 361 In GNS, every "." in a name delegates to another zone, and GNS 362 lookups are expected to return all of the required useful information 363 in one record set. This is incompatible with the special labels used 364 by DNS for SRV and TLSA records. Thus, GNS defines the BOX record 365 format to box up SRV and TLSA records and include them in the record 366 set of the label they are associated with. For example, a TLSA 367 record for "_https._tcp.example.org" will be stored in the record set 368 of "example.org" as a BOX record with service (SVC) 443 (https) and 369 protocol (PROTO) 6 (tcp) and record TYPE "TLSA". For reference, see 370 also [RFC2782]. A BOX DATA entry has the following format: 372 0 8 16 24 32 40 48 56 373 +-----+-----+-----+-----+-----+-----+-----+-----+ 374 | PROTO | SVC | TYPE | 375 +-----------+-----------------------------------+ 376 | RECORD DATA | 377 / / 378 / / 379 | | 380 +-----+-----+-----+-----+-----+-----+-----+-----+ 382 Figure 7 384 where: 386 PROTO the 16-bit protocol number, e.g. 6 for tcp. In network byte 387 order. 389 SVC the 16-bit service value of the boxed record, i.e. the port 390 number. In network byte order. 392 TYPE is the 32-bit record type of the boxed record. In network byte 393 order. 395 RECORD DATA is a variable length field containing the "DATA" format 396 of TYPE as defined for the respective TYPE in DNS. 398 3.7. VPN 400 A VPN DATA entry has the following format: 402 0 8 16 24 32 40 48 56 403 +-----+-----+-----+-----+-----+-----+-----+-----+ 404 | HOSTING PEER PUBLIC KEY | 405 | (256 bits) | 406 | | 407 | | 408 +-----------+-----------------------------------+ 409 | PROTO | SERVICE NAME | 410 +-----------+ + 411 / / 412 / / 413 | | 414 +-----+-----+-----+-----+-----+-----+-----+-----+ 415 Figure 8 417 where: 419 HOSTING PEER PUBLIC KEY is a 256-bit EdDSA public key identifying 420 the peer hosting the service. 422 PROTO the 16-bit protocol number, e.g. 6 for TCP. In network byte 423 order. 425 SERVICE NAME a shared secret used to identify the service at the 426 hosting peer, used to derive the port number requird to connect to 427 the service. The service name MUST be a 0-terminated UTF-8 428 string. 430 4. Publishing Records 432 GNS resource records are published in a distributed hash table (DHT). 433 We assume that a DHT provides two functions: GET(key) and 434 PUT(key,value). In GNS, resource records are grouped by their 435 respective labels, encrypted and published together in a single 436 resource records block (RRBLOCK) in the DHT under a key "q": PUT(q, 437 RRBLOCK). The key "q" which is derived from the zone key "zk" and 438 the respective label of the contained records. 440 4.1. Key Derivations 442 Given a label, the DHT key "q" is derived as follows: 444 PRK_h := HKDF-Extract ("key-derivation", zk) 445 h := HKDF-Expand (PRK_h, label | "gns", 512 / 8) 446 d_h := h * d mod L 447 zk_h := h mod L * zk 448 q := SHA512 (zk_h) 450 We use a hash-based key derivation function (HKDF) as defined in 451 [RFC5869]. We use HMAC-SHA512 for the extraction phase and HMAC- 452 SHA256 for the expansion phase. 454 PRK_h is key material retrieved using an HKDF using the string "key- 455 derivation" as salt and the public zone key "zk" as initial keying 456 material. 458 h is the 512-bit HKDF expansion result. The expansion info input is 459 a concatenation of the label and string "gns". 461 d is the 256-bit private zone key as defined in Section 2. 463 label is a UTF-8 string under which the resource records are 464 published. 466 d_h is a 256-bit private key derived from the "d" using the keying 467 material "h". 469 zk_h is a 256-bit public key derived from the zone key "zk" using 470 the keying material "h". 472 L is the prime-order subgroup as defined in Section 2. 474 q Is the 512-bit DHT key under which the resource records block is 475 published. It is the SHA512 hash over the public key "zk_h" 476 corresponding to the derived private key "d_h". 478 We point out that the multiplication of "zk" with "h" is a point 479 multiplication, while the multiplication of "d" with "h" is a scalar 480 multiplication. 482 4.2. Resource Records Block 484 GNS records are grouped by their labels and published as a single 485 block in the DHT. The grouped record sets MAY be paired with any 486 number of supplemental records. Supplemental records must have the 487 supplemental flag set (See Section 3). The contained resource 488 records are encrypted using a symmetric encryption scheme. A GNS 489 implementation must publish RRBLOCKs in accordance to the properties 490 and recommendations of the underlying DHT. This may include a 491 periodic refresh publication. A GNS RRBLOCK has the following 492 format: 494 0 8 16 24 32 40 48 56 495 +-----+-----+-----+-----+-----+-----+-----+-----+ 496 | SIGNATURE | 497 | | 498 | | 499 | | 500 | | 501 | | 502 | | 503 | | 504 +-----+-----+-----+-----+-----+-----+-----+-----+ 505 | PUBLIC KEY | 506 | | 507 | | 508 | | 509 +-----+-----+-----+-----+-----+-----+-----+-----+ 510 | SIZE | PURPOSE | 511 +-----+-----+-----+-----+-----+-----+-----+-----+ 512 | EXPIRATION | 513 +-----+-----+-----+-----+-----+-----+-----+-----+ 514 | BDATA / 515 / / 516 / | 517 +-----+-----+-----+-----+-----+-----+-----+-----+ 519 Figure 9 521 where: 523 SIGNATURE A 512-bit ECDSA deterministic signature compliant with 524 [RFC6979]. The signature is computed over the data following the 525 PUBLIC KEY field. The signature is created using the derived 526 private key "d_h" (see Section 4). 528 PUBLIC KEY is the 256-bit public key "zk_h" to be used to verify 529 SIGNATURE. The wire format of this value is defined in [RFC8032], 530 Section 5.1.5. 532 SIZE A 32-bit value containing the length of the signed data 533 following the PUBLIC KEY field in network byte order. This value 534 always includes the length of the fields SIZE (4), PURPOSE (4) and 535 EXPIRATION (8) in addition to the length of the BDATA. While a 536 32-bit value is used, implementations MAY refuse to publish blocks 537 beyond a certain size significantly below 4 GB. However, a 538 minimum block size of 62 kilobytes MUST be supported. 540 PURPOSE A 32-bit signature purpose flag. This field MUST be 15 (in 541 network byte order). 543 EXPIRATION Specifies when the RRBLOCK expires and the encrypted 544 block SHOULD be removed from the DHT and caches as it is likely 545 stale. However, applications MAY continue to use non-expired 546 individual records until they expire. The value MUST be set to 547 the expiration time of the resource record contained within this 548 block with the smallest expiration time. If a records block 549 includes shadow records, then the maximum expiration time of all 550 shadow records with matching type and the expiration times of the 551 non-shadow records is considered. This is a 64-bit absolute date 552 in microseconds since midnight (0 hour), January 1, 1970 in 553 network byte order. 555 BDATA The encrypted resource records with a total size of SIZE - 16. 557 4.3. Record Data Encryption and Decryption 559 A symmetric encryption scheme is used to encrypt the resource records 560 set RDATA into the BDATA field of a GNS RRBLOCK. The wire format of 561 the RDATA looks as follows: 563 0 8 16 24 32 40 48 56 564 +-----+-----+-----+-----+-----+-----+-----+-----+ 565 | RR COUNT | EXPIRA- / 566 +-----+-----+-----+-----+-----+-----+-----+-----+ 567 / -TION | DATA SIZE | 568 +-----+-----+-----+-----+-----+-----+-----+-----+ 569 | TYPE | FLAGS | 570 +-----+-----+-----+-----+-----+-----+-----+-----+ 571 | DATA / 572 / / 573 / | 574 +-----+-----+-----+-----+-----+-----+-----+-----+ 575 | EXPIRATION | 576 +-----+-----+-----+-----+-----+-----+-----+-----+ 577 | DATA SIZE | TYPE | 578 +-----+-----+-----+-----+-----+-----+-----+-----+ 579 | FLAGS | DATA / 580 +-----+-----+-----+-----+ / 581 / +-----------------------/ 582 / | / 583 +-----------------------+ / 584 / PADDING / 585 / / 587 Figure 10 589 where: 591 RR COUNT A 32-bit value containing the number of variable-length 592 resource records which are following after this field in network 593 byte order. 595 EXPIRATION, DATA SIZE, TYPE, FLAGS and DATA These fields were 596 defined in the resource record format in Section 3. There MUST be 597 a total of RR COUNT of these resource records present. 599 PADDING The padding MUST contain the value 0 in all octets. The 600 padding MUST ensure that the size of the RDATA WITHOUT the RR 601 COUNT field is a power of two. As a special exception, record 602 sets with (only) a PKEY record type are never padded. Note that a 603 record set with a PKEY record MUST NOT contain other records. 605 The symmetric keys and initialization vectors are derived from the 606 record label and the zone key "zk". For decryption of the resource 607 records block payload, the key material "K" and initialization vector 608 "IV" for the symmetric cipher are derived as follows: 610 PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk) 611 PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk) 612 K := HKDF-Expand (PRK_k, label, 512 / 8); 613 IV := HKDF-Expand (PRK_iv, label, 256 / 8) 615 HKDF is a hash-based key derivation function as defined in [RFC5869]. 616 Specifically, HMAC-SHA512 is used for the extraction phase and HMAC- 617 SHA256 for the expansion phase. The output keying material is 64 618 octets (512 bit) for the symmetric keys and 32 octets (256 bit) for 619 the initialization vectors. We divide the resulting keying material 620 "K" into a 256-bit AES [RFC3826] key and a 256-bit TWOFISH [TWOFISH] 621 key: 623 0 8 16 24 32 40 48 56 624 +-----+-----+-----+-----+-----+-----+-----+-----+ 625 | AES KEY | 626 | | 627 | | 628 | | 629 +-----+-----+-----+-----+-----+-----+-----+-----+ 630 | TWOFISH KEY | 631 | | 632 | | 633 | | 634 +-----+-----+-----+-----+-----+-----+-----+-----+ 636 Figure 11 638 Similarly, we divide "IV" into a 128-bit initialization vector and a 639 128-bit initialization vector: 641 0 8 16 24 32 40 48 56 642 +-----+-----+-----+-----+-----+-----+-----+-----+ 643 | AES IV | 644 | | 645 +-----+-----+-----+-----+-----+-----+-----+-----+ 646 | TWOFISH IV | 647 | | 648 +-----+-----+-----+-----+-----+-----+-----+-----+ 650 Figure 12 652 The keys and IVs are used for a CFB128-AES-256 and CFB128-TWOFISH-256 653 chained symmetric cipher. Both ciphers are used in Cipher FeedBack 654 (CFB) mode [RFC3826]. 656 RDATA := AES(K[0:31], IV[0:15], 657 TWOFISH(K[32:63], IV[16:31], BDATA)) 658 BDATA := TWOFISH(K[32:63], IV[16:31], 659 AES(K[0:31], IV[0:15], RDATA)) 661 5. Internationalization and Character Encoding 663 All labels in GNS are encoded in UTF-8 [RFC3629]. This does not 664 include any DNS names found in DNS records, such as CNAME records, 665 which are internationalized through the IDNA specifications 666 [RFC5890]. 668 6. Name Resolution 670 Names in GNS are resolved by recursively querying the DHT record 671 storage. In the following, we define how resolution is initiated and 672 each iteration in the resolution is processed. 674 GNS resolution of a name must start in a given starting zone 675 indicated using a zone public key. Details on how the starting zone 676 may be determined is discussed in Section 8. 678 When GNS name resolution is requested, a desired record type MAY be 679 provided by the client. The GNS resolver will use the desired record 680 type to guide processing, for example by providing conversion of VPN 681 records to A or AAAA records, if that is desired. However, filtering 682 of record sets according to the required record types MUST still be 683 done by the client after the resource record set is retrieved. 685 6.1. Recursion 687 In each step of the recursive name resolution, there is an 688 authoritative zone zk and a name to resolve. The name may be empty. 689 Initially, the authoritative zone is the start zone. If the name is 690 empty, it is interpreted as the apex label "@". 692 From here, the following steps are recursively executed, in order: 694 1. Extract the right-most label from the name to look up. 696 2. Calculate q using the label and zk as defined in Section 4.1. 698 3. Perform a DHT query GET(q) to retrieve the RRBLOCK. 700 4. Verify and process the RRBLOCK and decrypt the BDATA contained in 701 it as defined in Section 4.3. 703 Upon receiving the RRBLOCK from the DHT, apart from verifying the 704 provided signature, the resolver MUST check that the authoritative 705 zone key was used to sign the record: The derived zone key "h*zk" 706 MUST match the public key provided in the RRBLOCK, otherwise the 707 RRBLOCK MUST be ignored and the DHT lookup GET(q) MUST continue. 709 6.2. Record Processing 711 Record processing occurs at the end of a single recursion. We assume 712 that the RRBLOCK has been cryptographically verified and decrypted. 713 At this point, we must first determine if we have received a valid 714 record set in the context of the name we are trying to resolve: 716 1. Case 1: If the remainder of the name to resolve is empty and the 717 record set does not consist of a PKEY, CNAME or DNS2GNS record, 718 the record set is the result and the recursion is concluded. 720 2. Case 2: If the name to be resolved is of the format 721 "_SERVICE._PROTO" and the record set contains one or more 722 matching BOX records, the records in the BOX records are the 723 result and the recusion is concluded (Section 6.2.4). 725 3. Case 3: If the remainder of the name to resolve is not empty and 726 does not match the "_SERVICE._PROTO" syntax, then the current 727 record set MUST consist of a single PKEY record (Section 6.2.1), 728 a single CNAME record (Section 6.2.3), or one or more GNS2DNS 729 records (Section 6.2.2), which are processed as described in the 730 respective sections below. The record set may include any number 731 of supplemental records. Otherwise, resolution fails and the 732 resolver MUST return an empty record set. Finally, after the 733 recursion terminates, the client preferences for the record type 734 SHOULD be considered. If a VPN record is found and the client 735 requests an A or AAAA record, the VPN record SHOULD be converted 736 (Section 6.2.5) if possible. 738 6.2.1. PKEY 740 When the resolver encounters a PKEY record and the remainder of the 741 name is not empty, resolution continues recursively with the 742 remainder of the name in the GNS zone specified in the PKEY record. 744 If the remainder of the name to resolve is empty and we have received 745 a record set containing only a single PKEY record, the recursion is 746 continued with the PKEY as authoritative zone and the empty apex 747 label "@" as remaining name, except in the case where the desired 748 record type is PKEY, in which case the PKEY record is returned and 749 the resolution is concluded without resolving the empty apex label. 751 6.2.2. GNS2DNS 753 When a resolver encounters one or more GNS2DNS records and the 754 remaining name is empty and the desired record type is GNS2DNS, the 755 GNS2DNS records are returned. 757 Otherwise, it is expected that the resolver first resolves the IP(s) 758 of the specified DNS name server(s). GNS2DNS records MAY contain 759 numeric IPv4 or IPv6 addresses, allowing the resolver to skip this 760 step. The DNS server names may themselves be names in GNS or DNS. 761 If the DNS server name ends in ".+", the rest of the name is to be 762 interpreted relative to the zone of the GNS2DNS record. If the DNS 763 server name ends in ".", the DNS server name is to be 764 resolved against the GNS zone zk. 766 Multiple GNS2DNS records may be stored under the same label, in which 767 case the resolver MUST try all of them. The resolver MAY try them in 768 any order or even in parallel. If multiple GNS2DNS records are 769 present, the DNS name MUST be identical for all of them, if not the 770 resolution fails and an emtpy record set is returned as the record 771 set is invalid. 773 Once the IP addresses of the DNS servers have been determined, the 774 DNS name from the GNS2DNS record is appended to the remainder of the 775 name to be resolved, and resolved by querying the DNS name server(s). 776 As the DNS servers specified are possibly authoritative DNS servers, 777 the GNS resolver MUST support recursive resolution and MUST NOT 778 delegate this to the authoritative DNS servers. The first successful 779 recursive name resolution result is returned to the client. In 780 addition, the resolver returns the queried DNS name as a supplemental 781 LEHO record (Section 3.4) with a relative expiration time of one 782 hour. 784 GNS resolvers SHOULD offer a configuration option to disable DNS 785 processing to avoid information leakage and provide a consistent 786 security profile for all name resolutions. Such resolvers would 787 return an empty record set upon encountering a GNS2DNS record during 788 the recursion. However, if GNS2DNS records are encountered in the 789 record set for the apex and a GNS2DNS record is expicitly requested 790 by the application, such records MUST still be returned, even if DNS 791 support is disabled by the GNS resolver configuration. 793 6.2.3. CNAME 795 If a CNAME record is encountered, the canonical name is appended to 796 the remaining name, except if the remaining name is empty and the 797 desired record type is CNAME, in which case the resolution concludes 798 with the CNAME record. If the canonical name ends in ".+", 799 resolution continues in GNS with the new name in the current zone. 800 Otherwise, the resulting name is resolved via the default operating 801 system name resolution process. This may in turn again trigger a GNS 802 resolution process depending on the system configuration. 804 The recursive DNS resolution process may yield a CNAME as well which 805 in turn may either point into the DNS or GNS namespace (if it ends in 806 a "."). In order to prevent infinite loops, the resolver 807 MUST implement loop detections or limit the number of recursive 808 resolution steps. If the last CNAME was a DNS name, the resolver 809 returns the DNS name as a supplemental LEHO record (Section 3.4) with 810 a relative expiration time of one hour. 812 6.2.4. BOX 814 When a BOX record is received, a GNS resolver must unbox it if the 815 name to be resolved continues with "_SERVICE._PROTO". Otherwise, the 816 BOX record is to be left untouched. This way, TLSA (and SRV) records 817 do not require a separate network request, and TLSA records become 818 inseparable from the corresponding address records. 820 6.2.5. VPN 822 At the end of the recursion, if the queried record type is either A 823 or AAAA and the retrieved record set contains at least one VPN 824 record, the resolver SHOULD open a tunnel and return the IPv4 or IPv6 825 tunnel address, respectively. The type of tunnel depends on the 826 contents of the VPN record data. The VPN record MUST be returned if 827 the resolver implementation does not support setting up a tunnnel. 829 6.2.6. NICK 831 NICK records are only relevant to the recursive resolver if the 832 record set in question is the final result which is to be returned to 833 the client. The encountered NICK records may either be supplemental 834 (see Section 3) or non-supplemental. If the NICK record is 835 supplemental, the resolver only returns the record set if one of the 836 non-supplemental records matches the queried record type. 838 The differentiation between a supplemental and non-supplemental NICK 839 record allows the client to match the record to the authoritative 840 zone. Consider the following example: 842 Query: alice.example (type=A) 843 Result: 844 A: 192.0.2.1 845 NICK: eve 847 Figure 13 849 In this example, the returned NICK record is non-supplemental. For 850 the client, this means that the NICK belongs to the zone "alice.doe" 851 and is published under the empty label along with an A record. The 852 NICK record should be interpreted as: The zone defined by "alice.doe" 853 wants to be referred to as "eve". In contrast, consider the 854 following: 856 Query: alice.example (type=AAAA) 857 Result: 858 AAAA: 2001:DB8::1 859 NICK: john (Supplemental) 861 Figure 14 863 In this case, the NICK record is marked as supplemental. This means 864 that the NICK record belongs to the zone "doe" and is published under 865 the label "alice" along with an A record. The NICK record should be 866 interpreted as: The zone defined by "doe" wants to be referred to as 867 "john". This distinction is likely useful for other records 868 published as supplemental. 870 7. Zone Revocation 872 Whenever a recursive resolver encounters a new GNS zone, it MUST 873 check against the local revocation list whether the respective zone 874 key has been revoked. If the zone key was revoked, the resolution 875 MUST fail with an empty result set. 877 In order to revoke a zone key, a signed revocation object SHOULD be 878 published. This object MUST be signed using the private zone key. 879 The revocation object is flooded in the overlay network. To prevent 880 flooding attacks, the revocation message MUST contain a proof of work 881 (PoW). The revocation message including the PoW MAY be calculated 882 ahead of time to support timely revocation. 884 For all occurences below, "Argon2id" is the Password-based Key 885 Derivation Function as defined in [Argon2]. For the PoW calculations 886 the algorithm is instantiated with the following parameters: 888 S The salt. Fixed 16-octet string: "GnsRevocationPow". 890 t Number of iterations: 3 892 m Memory size in KiB: 1024 894 T Output length of hash in bytes: 64 896 p Parallelization parameter: 1 898 v Algorithm version: 0x13 900 y Algorithm type (Argon2id): 2 902 X Unused 904 K Unused 906 The following is the message string "P" on which the PoW is 907 calculated: 909 0 8 16 24 32 40 48 56 910 +-----+-----+-----+-----+-----+-----+-----+-----+ 911 | POW | 912 +-----------------------------------------------+ 913 | TIMESTAMP | 914 +-----------------------------------------------+ 915 | PUBLIC KEY | 916 | | 917 | | 918 | | 919 +-----+-----+-----+-----+-----+-----+-----+-----+ 921 Figure 15 923 where: 925 POW A 64-bit solution to the PoW. In network byte order. 927 TIMESTAMP denotes the absolute 64-bit date when the revocation was 928 computed. In microseconds since midnight (0 hour), January 1, 929 1970 in network byte order. 931 PUBLIC KEY is the 256-bit public key "zk" of the zone which is being 932 revoked and the key to be used to verify SIGNATURE. The wire 933 format of this value is defined in [RFC8032], Section 5.1.5. 935 Traditionally, PoW schemes require to find a "POW" such that at least 936 D leading zeroes are found in the hash result. D is then referred to 937 as the "difficulty" of the PoW. In order to reduce the variance in 938 time it takes to calculate the PoW, we require that a number "Z" 939 different PoWs must be found that on average have "D" leading zeroes. 941 The resulting proofs may then published and disseminated. The 942 concrete dissemination and publication methods are out of scope of 943 this document. Given an average difficulty of "D", the proofs have 944 an expiration time of EPOCH. With each additional bit difficulty, 945 the lifetime of the proof is prolonged for another EPOCH. 946 Consequently, by calculating a more difficult PoW, the lifetime of 947 the proof can be increased on demand by the zone owner. 949 The parameters are defined as follows: 951 Z The number of PoWs required is fixed at 32. 953 D The difficulty is fixed at 25. 955 EPOCH A single epoch is fixed at 365 days. 957 Given that proof has been found, a revocation data object is defined 958 as follows: 960 0 8 16 24 32 40 48 56 961 +-----+-----+-----+-----+-----+-----+-----+-----+ 962 | TIMESTAMP | 963 +-----+-----+-----+-----+-----+-----+-----+-----+ 964 | TTL | 965 +-----+-----+-----+-----+-----+-----+-----+-----+ 966 | POW_0 | 967 +-----+-----+-----+-----+-----+-----+-----+-----+ 968 | ... | 969 +-----+-----+-----+-----+-----+-----+-----+-----+ 970 | POW_Z-1 | 971 +-----------------------------------------------+ 972 | SIGNATURE | 973 | | 974 | | 975 | | 976 | | 977 | | 978 | | 979 | | 980 +-----+-----+-----+-----+-----+-----+-----+-----+ 981 | PUBLIC KEY | 982 | | 983 | | 984 | | 985 +-----+-----+-----+-----+-----+-----+-----+-----+ 987 Figure 16 989 where: 991 TIMESTAMP denotes the absolute 64-bit date when the revocation was 992 computed. In microseconds since midnight (0 hour), January 1, 993 1970 in network byte order. This is the same value as the 994 timestamp used in the individual PoW calculations. 996 TTL denotes the relative 64-bit time to live of of the record in 997 microseconds also in network byte order. This field is 998 informational for a verifier. The verifier may discard revocation 999 if the TTL indicates that it is already expired. However, the 1000 actual TTL of the revocation must be determined by examining the 1001 leading zeros in the proof of work calculation. 1003 POW_i The values calculated as part of the PoW, in network byte 1004 order. Each POW_i MUST be unique in the set of POW values. To 1005 facilitate fast verification of uniqueness, the POW values must be 1006 given in strictly monotonically increasing order in the message. 1008 SIGNATURE A 512-bit ECDSA deterministic signature compliant with 1009 [RFC6979] over the public zone zk of the zone which is revoked and 1010 corresponds to the key used in the PoW. The signature is created 1011 using the private zone key "d" (see Section 2). 1013 PUBLIC KEY is the 256-bit public key "zk" of the zone which is being 1014 revoked and the key to be used to verify SIGNATURE. The wire 1015 format of this value is defined in [RFC8032], Section 5.1.5. 1017 The signature over the public key covers a 32 bit pseudo header 1018 conceptually prefixed to the public key. The pseudo header includes 1019 the key length and signature purpose: 1021 0 8 16 24 32 40 48 56 1022 +-----+-----+-----+-----+-----+-----+-----+-----+ 1023 | SIZE (0x30) | PURPOSE (0x03) | 1024 +-----+-----+-----+-----+-----+-----+-----+-----+ 1025 | PUBLIC KEY | 1026 | | 1027 | | 1028 | | 1029 +-----+-----+-----+-----+-----+-----+-----+-----+ 1030 | TIMESTAMP | 1031 +-----+-----+-----+-----+-----+-----+-----+-----+ 1033 Figure 17 1035 where: 1037 SIZE A 32-bit value containing the length of the signed data in 1038 bytes (48 bytes) in network byte order. 1040 PURPOSE A 32-bit signature purpose flag. This field MUST be 3 (in 1041 network byte order). 1043 PUBLIC KEY / TIMESTAMP Both values as defined in the revocation data 1044 object above. 1046 In order to verify a revocation the following steps must be taken, in 1047 order: 1049 1. The current time MUST be between TIMESTAMP and TIMESTAMP+TTL. 1051 2. The signature MUST match the public key. 1053 3. The set of POW values MUST NOT contain duplicates. 1055 4. The average number of leading zeroes resulting from the provided 1056 POW values D' MUST be greater than D. 1058 5. The validation period (TTL) of the revocation is calculated as 1059 (D'-D) * EPOCH * 1.1. The EPOCH is extended by 10% in order to 1060 deal with unsynchronized clocks. The TTL added on top of the 1061 TIMESTAMP yields the expiration date. 1063 8. Determining the Root Zone and Zone Governance 1065 The resolution of a GNS name must start in a given start zone 1066 indicated to the resolver using any public zone key. The local 1067 resolver may have a local start zone configured/hard-coded which 1068 points to a local or remote start zone key. A resolver client may 1069 also determine the start zone from the suffix of the name given for 1070 resolution or using information retrieved out of band. The 1071 governance model of any zone is at the sole discretion of the zone 1072 owner. However, the choice of start zone(s) is at the sole 1073 discretion of the local system administrator or user. 1075 This is an important distinguishing factor from the Domain Name 1076 System where root zone governance is centralized at the Internet 1077 Corporation for Assigned Names and Numbers (ICANN). In DNS 1078 terminology, GNS roughly follows the idea of a hyper-hyper local root 1079 zone deployment, with the difference that it is not expected that all 1080 deployments use the same local root zone. 1082 In the following, we give examples how a local client resolver SHOULD 1083 discover the start zone. The process given is not exhaustive and 1084 clients MAY suppliement it with other mechanisms or ignore it if the 1085 particular application requires a different process. 1087 GNS clients SHOULD first try to interpret the top-level domain of a 1088 GNS name as a zone key. For example. if the top-level domain is a 1089 Base32-encoded public zone key "zk", the root zone of the resolution 1090 process is implicitly given by the name: 1092 Example name: www.example. 1093 => Root zone: zk 1094 => Name to resolve from root zone: www.example 1096 In GNS, users MAY own and manage their own zones. Each local zone 1097 SHOULD be associated with a single GNS label, but users MAY choose to 1098 use longer names consisting of multiple labels. If the name of a 1099 locally managed zone matches the suffix of the name to be resolved, 1100 resolution SHOULD start from the respective local zone: 1102 Example name: www.example.org 1103 Local zones: 1104 fr = (d0,zk0) 1105 gnu = (d1,zk1) 1106 com = (d2,zk2) 1107 ... 1108 => Entry zone: zk1 1109 => Name to resolve from entry zone: www.example 1111 Finally, additional "suffix to zone" mappings MAY be configured. 1112 Suffix to zone key mappings SHOULD be configurable through a local 1113 configuration file or database by the user or system administrator. 1114 The suffix MAY consist of multiple GNS labels concatenated with a 1115 ".". If multiple suffixes match the name to resolve, the longest 1116 matching suffix MUST BE used. The suffix length of two results 1117 cannot be equal, as this would indicate a misconfiguration. If both 1118 a locally managed zone and a configuration entry exist for the same 1119 suffix, the locally managed zone MUST have priority. 1121 Example name: www.example.org 1122 Local suffix mappings: 1123 gnu = zk0 1124 example.org = zk1 1125 example.com = zk2 1126 ... 1127 => Entry zone: zk1 1128 => Name to resolve from entry zone: www 1130 9. Security Considerations 1132 9.1. Cryptography 1134 The security of cryptographic systems depends on both the strength of 1135 the cryptographic algorithms chosen and the strength of the keys used 1136 with those algorithms. The security also depends on the engineering 1137 of the protocol used by the system to ensure that there are no non- 1138 cryptographic ways to bypass the security of the overall system. 1140 This document concerns itself with the selection of cryptographic 1141 algorithms for use in GNS. The algorithms identified in this 1142 document are not known to be broken (in the cryptographic sense) at 1143 the current time, and cryptographic research so far leads us to 1144 believe that they are likely to remain secure into the foreseeable 1145 future. However, this isn't necessarily forever, and it is expected 1146 that new revisions of this document will be issued from time to time 1147 to reflect the current best practices in this area. 1149 GNS uses ECDSA over Curve25519. This is an unconventional choice, as 1150 ECDSA is usually used with other curves. However, traditional ECDSA 1151 curves are problematic for a range of reasons described in the 1152 Curve25519 and EdDSA papers. Using EdDSA directly is also not 1153 possible, as a hash function is used on the private key which 1154 destroys the linearity that the GNU Name System depends upon. We are 1155 not aware of anyone suggesting that using Curve25519 instead of 1156 another common curve of similar size would lower the security of 1157 ECDSA. GNS uses 256-bit curves because that way the encoded (public) 1158 keys fit into a single DNS label, which is good for usability. 1160 In terms of crypto-agility, whenever the need for an updated 1161 cryptographic scheme arises to replace ECDSA over Curve25519 it may 1162 simply be introduced through a new record type. Such a new record 1163 type may then replace the PKEY record type for future records. The 1164 old record type remains and zones can iteratively migrate to the 1165 updated zone keys. 1167 9.2. Abuse mitigation 1169 GNS names are UTF-8 strings. Consequently, GNS faces similar issues 1170 with respect to name spoofing as DNS does for internationalized 1171 domain names. In DNS, attackers may register similar sounding or 1172 looking names (see above) in order to execute phishing attacks. GNS 1173 zone administrators must take into account this attack vector and 1174 incorporate rules in order to mitigate it. 1176 Further, DNS can be used to combat illegal content on the internet by 1177 having the respective domains seized by authorities. However, the 1178 same mechanisms can also be abused in order to impose state 1179 censorship, which ist one of the motivations behind GNS. Hence, such 1180 a seizure is, by design, difficult to impossible in GNS. In 1181 particular, GNS does not support WHOIS ([RFC3912]). 1183 9.3. Zone management 1185 In GNS, zone administrators need to manage and protect their zone 1186 keys. Once a zone key is lost it cannot be recovered. Once it is 1187 compromised it cannot be revoked (unless a revocation message was 1188 pre-calculated and is still available). Zone administrators, and for 1189 GNS this includes end-users, are required to responsibly and 1190 dilligently protect their cryptographic keys. Offline signing is in 1191 principle possible, but GNS does not support separate zone signing 1192 and key-signing keys (as in [RFC6781]) in order to provide usable 1193 security. 1195 Similarly, users are required to manage their local root zone. In 1196 order to ensure integrity and availability or names, users must 1197 ensure that their local root zone information is not compromised or 1198 outdated. It can be expected that the processing of zone revocations 1199 and an initial root zone is provided with a GNS client implementation 1200 ("drop shipping"). Extension and customization of the zone is at the 1201 full discretion of the user. 1203 9.4. Impact of underlying DHT 1205 This document does not specifiy the properties of the underlying 1206 distributed hash table (DHT) which is required by any GNS 1207 implementation. For implementors, it is important to note that the 1208 properties of the DHT are directly inherited by the GNS 1209 implementation. This includes both security as well as other non- 1210 functional properties such as scalability and performance. 1211 Implementors should take great care when selecting or implementing a 1212 DHT for use in a GNS implementation. DHTs with string security and 1213 performance guarantees exist [R5N]. It should also be taken into 1214 consideration that GNS implementations which build upon different DHT 1215 overlays are unlikely to be interoperable with each other. 1217 9.5. Revocations 1219 Zone administrators are advised to pre-generate zone revocations and 1220 securely store the revocation information in case the zone key is 1221 lost, compromised or replaced in the furture. Pre-calculated 1222 revocations may become invalid due to expirations or protocol changes 1223 such as epoch adjustments. Consequently, implementors and users must 1224 make precautions in order to manage revocations accordingly. 1226 Revocation payloads do NOT include a 'new' key for key replacement. 1227 Inclusion of such a key would have two major disadvantages: 1229 If revocation is used after a private key was compromised, allowing 1230 key replacement would be dangerous: if an adversary took over the 1231 private key, the adversary could then broadcast a revocation with a 1232 key replacement. For the replacement, the compromised owner would 1233 have no chance to issue even a revocation. Thus, allowing a 1234 revocation message to replace a private key makes dealing with key 1235 compromise situations worse. 1237 Sometimes, key revocations are used with the objective of changing 1238 cryptosystems. Migration to another cryptosystem by replacing keys 1239 via a revocation message would only be secure as long as both 1240 cryptosystems are still secure against forgery. Such a planned, non- 1241 emergency migration to another cryptosystem should be done by running 1242 zones for both ciphersystems in parallel for a while. The migration 1243 would conclude by revoking the legacy zone key only once it is deemed 1244 no longer secure, and hopefully after most users have migrated to the 1245 replacement. 1247 10. GANA Considerations 1249 GANA is requested to create an "GNU Name System Record Types" 1250 registry. The registry shall record for each entry: 1252 * Name: The name of the record type (case-insensitive ASCII string, 1253 restricted to alphanumeric characters 1255 * Number: 32-bit, above 65535 1257 * Comment: Optionally, a brief English text describing the purpose 1258 of the record type (in UTF-8) 1260 * Contact: Optionally, the contact information of a person to 1261 contact for further information 1263 * References: Optionally, references describing the record type 1264 (such as an RFC) 1266 The registration policy for this sub-registry is "First Come First 1267 Served", as described in [RFC8126]. GANA is requested to populate 1268 this registry as follows: 1270 Number | Name | Contact | References | Description 1271 -------+---------+---------+------------+------------------------- 1272 65536 | PKEY | N/A | [This.I-D] | GNS zone delegation 1273 65537 | NICK | N/A | [This.I-D] | GNS zone nickname 1274 65538 | LEHO | N/A | [This.I-D] | GNS legacy hostname 1275 65539 | VPN | N/A | [This.I-D] | VPN resolution 1276 65540 | GNS2DNS | N/A | [This.I-D] | Delegation to DNS 1277 65541 | BOX | N/A | [This.I-D] | Boxed record 1279 Figure 18 1281 GANA is requested to amend the "GNUnet Signature Purpose" registry as 1282 follows: 1284 Purpose | Name | References | Description 1285 --------+-----------------+------------+-------------------------- 1286 3 | GNS_REVOCATION | [This.I-D] | GNS zone key revocation 1287 15 | GNS_RECORD_SIGN | [This.I-D] | GNS record set signature 1289 Figure 19 1291 11. Test Vectors 1293 The following represents a test vector for a record set with a DNS 1294 record of type "A" as well as a GNS record of type "PKEY" under the 1295 label "test". 1297 Zone private key (d, little-endian scalar): 1298 3015471ecb45455b5e9df50ff416b3d53aa6db6cafec858449f788142d091d41 1300 Zone public key (zk): 1301 bf06e687a291a509b6326bb6394dd6ed3ff9e5eb78ea5752ed0eba0807023a33 1303 Label: test 1304 RRCOUNT: 2 1306 Record #0 1307 EXPIRATION: 1590482415557079 1308 DATA_SIZE: 4 1309 TYPE: 1 1310 FLAGS: 0 1311 DATA: 1312 01020304 1314 Record #1 1315 EXPIRATION: 1590482415557079 1316 DATA_SIZE: 32 1317 TYPE: 65536 1318 FLAGS: 2 1319 DATA: 1320 814fbb06b17f4ecf 1321 d098700619179f9d 1322 4aef24465bd6958a 1323 e4ed01cd024b1856 1325 RDATA: 1326 0005a6890b6699d7 1327 0000000400000001 1328 0000000001020304 1329 0005a6890b6699d7 1330 0000002000010000 1331 00000002814fbb06 1332 b17f4ecfd0987006 1333 19179f9d4aef2446 1334 5bd6958ae4ed01cd 1335 024b185600000000 1336 0000000000000000 1337 0000000000000000 1338 0000000000000000 1339 0000000000000000 1340 0000000000000000 1341 0000000000000000 1343 BDATA: 1344 9f471611a5c06fc2 1345 c9ad33f642dd315c 1346 f8fc675aed23e8a1 1347 d19a5bad657557fe 1348 6e1d50709860593e 1349 5376c30f6f22daac 1350 5293986b7444476d 1351 b8f289f5537da168 1352 dc81cba256d8401b 1353 642dbe6a24346e11 1354 9148ade8acb4d5e5 1355 cef5eb5ad1e3b95d 1356 d143123d387b8df0 1357 ba4e2d75a9eb94a4 1358 f3250b975fee90e9 1359 558bb9e1e009ca46 1360 b7a066dd 1362 RRBLOCK: 1363 08180a871b910ade 1364 a1125a1030d0f269 1365 069e5731c90ad0d0 1366 cfa10bf61b3f0c79 1367 0833b515d4c746e6 1368 4a7261947bfb6429 1369 21200bb97a96292d 1370 6abefab1197f7e4e 1371 b399c628a71d3627 1372 d64a2bd66080f64d 1373 91c0120ab14601d8 1374 18de23c8da82b80b 1375 000000940000000f 1376 0005a6890b6699d7 1377 9f471611a5c06fc2 1378 c9ad33f642dd315c 1379 f8fc675aed23e8a1 1380 d19a5bad657557fe 1381 6e1d50709860593e 1382 5376c30f6f22daac 1383 5293986b7444476d 1384 b8f289f5537da168 1385 dc81cba256d8401b 1386 642dbe6a24346e11 1387 9148ade8acb4d5e5 1388 cef5eb5ad1e3b95d 1389 d143123d387b8df0 1390 ba4e2d75a9eb94a4 1391 f3250b975fee90e9 1392 558bb9e1e009ca46 1393 b7a066dd 1395 The following is an example revocation for a zone: 1397 Zone private key (d, little-endian scalar): 1398 90ea2a95cb9ef482b45817dc45b805cae00f387022a065a3674f41ad15173c63 1400 Zone public key (zk): 1401 4ac1e51d9a585a9ad9fb0dfac2be100aee83f0cc79c4c5ea8f3eb8afd9092fa5 1403 Difficulty (5 base difficulty + 2 epochs): 7 1405 Proof: 1406 0005a5fd368978f4 1407 0000395d1827c000 1408 e23f657bc47ec853 1409 e23f657bc47ec9d8 1410 e23f657bc47ecaec 1411 e23f657bc47ecb29 1412 e23f657bc47ecc00 1413 e23f657bc47ecc79 1414 e23f657bc47ece83 1415 e23f657bc47ecfc6 1416 e23f657bc47ecfc8 1417 e23f657bc47ecfd5 1418 e23f657bc47ed02b 1419 e23f657bc47ed03b 1420 e23f657bc47ed0ff 1421 e23f657bc47ed241 1422 e23f657bc47ed264 1423 e23f657bc47ed2e5 1424 e23f657bc47ed343 1425 e23f657bc47ed348 1426 e23f657bc47ed45e 1427 e23f657bc47ed480 1428 e23f657bc47ed49a 1429 e23f657bc47ed564 1430 e23f657bc47ed565 1431 e23f657bc47ed5b6 1432 e23f657bc47ed5de 1433 e23f657bc47ed5e0 1434 e23f657bc47ed77f 1435 e23f657bc47ed800 1436 e23f657bc47ed80c 1437 e23f657bc47ed817 1438 e23f657bc47ed82c 1439 e23f657bc47ed8a6 1440 0396020c831a5405 1441 cee6c38842209191 1442 c8db799dbe81e0dc 1443 f6dbd4f91c257ae2 1444 0079e7fd1cd31cc2 1445 4cd9a52831d5ec30 1446 f10e22e5a6dd9065 1447 18746cfce2095610 1448 4ac1e51d9a585a9a 1449 d9fb0dfac2be100a 1450 ee83f0cc79c4c5ea 1451 8f3eb8afd9092fa5 1453 12. Normative References 1455 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1456 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1457 . 1459 [RFC1035] Mockapetris, P., "Domain names - implementation and 1460 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1461 November 1987, . 1463 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1464 specifying the location of services (DNS SRV)", RFC 2782, 1465 DOI 10.17487/RFC2782, February 2000, 1466 . 1468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1469 Requirement Levels", BCP 14, RFC 2119, 1470 DOI 10.17487/RFC2119, March 1997, 1471 . 1473 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1474 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1475 2003, . 1477 [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The 1478 Advanced Encryption Standard (AES) Cipher Algorithm in the 1479 SNMP User-based Security Model", RFC 3826, 1480 DOI 10.17487/RFC3826, June 2004, 1481 . 1483 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 1484 DOI 10.17487/RFC3912, September 2004, 1485 . 1487 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1488 Key Derivation Function (HKDF)", RFC 5869, 1489 DOI 10.17487/RFC5869, May 2010, 1490 . 1492 [RFC5890] Klensin, J., "Internationalized Domain Names for 1493 Applications (IDNA): Definitions and Document Framework", 1494 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1495 . 1497 [RFC5891] Klensin, J., "Internationalized Domain Names in 1498 Applications (IDNA): Protocol", RFC 5891, 1499 DOI 10.17487/RFC5891, August 2010, 1500 . 1502 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 1503 Operational Practices, Version 2", RFC 6781, 1504 DOI 10.17487/RFC6781, December 2012, 1505 . 1507 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 1508 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 1509 April 2013, . 1511 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 1512 Algorithm (DSA) and Elliptic Curve Digital Signature 1513 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 1514 2013, . 1516 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1517 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1518 2016, . 1520 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1521 Signature Algorithm (EdDSA)", RFC 8032, 1522 DOI 10.17487/RFC8032, January 2017, 1523 . 1525 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1526 Writing an IANA Considerations Section in RFCs", BCP 26, 1527 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1528 . 1530 [TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A 1531 128-Bit Block Cipher, 1st Edition", March 1999. 1533 [GNS] Wachs, M., Schanzenbach, M., and C. Grothoff, "A 1534 Censorship-Resistant, Privacy-Enhancing and Fully 1535 Decentralized Name System", 2014, 1536 . 1538 [R5N] Evans, N. S. and C. Grothoff, "R5N: Randomized recursive 1539 routing for restricted-route networks", 2011, 1540 . 1542 [Argon2] Biryukov, A., Dinu, D., Khovratovich, D., and S. 1543 Josefsson, "The memory-hard Argon2 password hash and 1544 proof-of-work function", March 2020, 1545 . 1548 Authors' Addresses 1550 Martin Schanzenbach 1551 GNUnet e.V. 1552 Boltzmannstrasse 3 1553 85748 Garching 1554 Germany 1556 Email: schanzen@gnunet.org 1558 Christian Grothoff 1559 Berner Fachhochschule 1560 Hoeheweg 80 1561 CH-2501 Biel/Bienne 1562 Switzerland 1564 Email: grothoff@gnunet.org 1565 Bernd Fix 1566 GNUnet e.V. 1567 Boltzmannstrasse 3 1568 85748 Garching 1569 Germany 1571 Email: fix@gnunet.org