Independent Stream M. Schanzenbach Internet-Draft GNUnet e.V. Intended status: Informational C. Grothoff Expires: 30 August 2022 Berner Fachhochschule B. Fix GNUnet e.V. 26 February 2022 The GNU Name System draft-schanzen-gns-10 Abstract This document contains the GNU Name System (GNS) technical specification. GNS is a decentralized and censorship-resistant name system that provides a privacy-enhancing alternative to the Domain Name System (DNS). This document defines the normative wire format of resource records, resolution processes, cryptographic routines and security considerations for use by implementers. This specification was developed outside the IETF and does not have IETF consensus. It is published here to inform readers about the function of GNS, guide future GNS implementations, and ensure interoperability among implementations including with the pre- existing GNUnet implementation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 30 August 2022. Schanzenbach, et al. Expires 30 August 2022 [Page 1] Internet-Draft The GNU Name System February 2022 Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Zone Top-Level Domain . . . . . . . . . . . . . . . . . . 9 4.2. Zone Revocation . . . . . . . . . . . . . . . . . . . . . 10 5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Zone Delegation Records . . . . . . . . . . . . . . . . . 16 5.1.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.2. EDKEY . . . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Redirection Records . . . . . . . . . . . . . . . . . . . 24 5.2.1. REDIRECT . . . . . . . . . . . . . . . . . . . . . . 25 5.2.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 25 5.3. Auxiliary Records . . . . . . . . . . . . . . . . . . . . 26 5.3.1. LEHO . . . . . . . . . . . . . . . . . . . . . . . . 26 5.3.2. NICK . . . . . . . . . . . . . . . . . . . . . . . . 27 5.3.3. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 28 6. Record Storage . . . . . . . . . . . . . . . . . . . . . . . 29 6.1. The Storage Key . . . . . . . . . . . . . . . . . . . . . 29 6.2. The Records Block . . . . . . . . . . . . . . . . . . . . 30 7. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 33 7.1. Start Zones . . . . . . . . . . . . . . . . . . . . . . . 33 7.2. Recursion . . . . . . . . . . . . . . . . . . . . . . . . 34 7.3. Record Processing . . . . . . . . . . . . . . . . . . . . 35 7.3.1. REDIRECT . . . . . . . . . . . . . . . . . . . . . . 36 7.3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 36 7.3.3. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 37 7.3.4. Zone Delegation Records . . . . . . . . . . . . . . . 38 7.3.5. NICK . . . . . . . . . . . . . . . . . . . . . . . . 38 8. Internationalization and Character Encoding . . . . . . . . . 39 9. Security and Privacy Considerations . . . . . . . . . . . . . 39 Schanzenbach, et al. Expires 30 August 2022 [Page 2] Internet-Draft The GNU Name System February 2022 9.1. Availability . . . . . . . . . . . . . . . . . . . . . . 39 9.2. Agility . . . . . . . . . . . . . . . . . . . . . . . . . 40 9.3. Cryptography . . . . . . . . . . . . . . . . . . . . . . 40 9.4. Abuse Mitigation . . . . . . . . . . . . . . . . . . . . 41 9.5. Zone Management . . . . . . . . . . . . . . . . . . . . . 42 9.6. Impact of DHTs as Underlying Storage . . . . . . . . . . 42 9.7. Revocations . . . . . . . . . . . . . . . . . . . . . . . 43 9.8. Label Guessing . . . . . . . . . . . . . . . . . . . . . 43 10. GANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 12. Implementation and Deployment Status . . . . . . . . . . . . 45 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 14. Normative References . . . . . . . . . . . . . . . . . . . . 46 15. Informative References . . . . . . . . . . . . . . . . . . . 48 Appendix A. Base32GNS . . . . . . . . . . . . . . . . . . . . . 50 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 1. Introduction The Domain Name System (DNS) [RFC1035] is a unique distributed database and a vital service for most Internet applications. While DNS is distributed, in practice it relies on centralized, trusted registrars to provide globally unique names. As the awareness of the central role DNS plays on the Internet rises, various institutions are using their power (including legal means) to engage in attacks on the DNS, thus threatening the global availability and integrity of information on the Internet. DNS was not designed with security in mind. This makes it very vulnerable, especially to attackers that have the technical capabilities of an entire nation state at their disposal. While a wider discussion of this issue is out of scope for this document, analyses and investigations can be found in recent academic research works including [SecureNS]. This specification describes a censorship-resistant, privacy- preserving and decentralized name system: The GNU Name System (GNS) [GNS]. It is designed to provide a secure, privacy-enhancing alternative to DNS, especially when censorship or manipulation is encountered. In particular, it directly addresses concerns in DNS with respect to "Query Privacy", the "Single Hierarchy with a Centrally Controlled Root" and "Distribution and Management of Root Servers" as raised in [RFC8324]. GNS can bind names to any kind of cryptographically secured token, enabling it to double in some respects as an alternative to some of today's Public Key Infrastructures, in particular X.509 for the Web. Schanzenbach, et al. Expires 30 August 2022 [Page 3] Internet-Draft The GNU Name System February 2022 The design of GNS incorporates the capability to integrate and coexist with DNS. GNS is based on the principle of a petname system and builds on ideas from the Simple Distributed Security Infrastructure [SDSI], addressing a central issue with the decentralized mapping of secure identifiers to memorable names: namely the impossibility of providing a global, secure and memorable mapping without a trusted authority. GNS uses the transitivity in the SDSI design to replace the trusted root with secure delegation of authority thus making petnames useful to other users while operating under a very strong adversary model. This is an important distinguishing factor from the Domain Name System where root zone governance is centralized at the Internet Corporation for Assigned Names and Numbers (ICANN). In DNS terminology, GNS roughly follows the idea of a hyperlocal root zone deployment, with the difference that it is not expected that all deployments use the same local root zone, and that users can easily delegate control of arbitrary domain names to arbitrary zones. This document defines the normative wire format of resource records, resolution processes, cryptographic routines and security considerations for use by implementers. This specification was developed outside the IETF and does not have IETF consensus. It is published here to guide implementation of GNS and to ensure interoperability among implementations. 1.1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Terminology Application An application refers to a component which uses a GNS implementation to resolve names into records and processes its contents. Name A name in GNS is a domain name as defined in [RFC8499] as an ordered list of labels. Names are UTF-8 [RFC3629] strings consisting of the list of labels concatenated with a label separator. Names are resolved starting from the rightmost label. GNS does not impose length restrictions on names or labels. However, applications MAY ensure that name and label lengths are compatible with DNS and in particular IDNA [RFC5890]. In the Schanzenbach, et al. Expires 30 August 2022 [Page 4] Internet-Draft The GNU Name System February 2022 spirit of [RFC5895], applications MAY preprocess names and labels to ensure compatibility with DNS or support specific user expectations, for example according to [Unicode-UTS46]. Label A GNS label is a label as defined in [RFC8499]. Labels are UTF-8 strings in Unicode Normalization Form C (NFC) [Unicode-UAX15]. The apex label, label separator and the extension label have special purposes in the resolution protocol which are defined in the rest of the document. Zone administrators MAY disallow certain labels that may be easily confused with other labels through registration policies. Apex Label The apex label is used to publish resource records in a zone that can be resolved without providing a specific label. It is the GNS method to provide what is the "zone apex" in DNS [RFC4033]. The apex label is represented using the character U+0040 ("@" without the quotes). Extension Label The primary use for the extension label is in redirections where the redirection target is defined relative to the authoritative zone of the redirection record (Section 5.2). The extension label is represented using the character U+002B ("+" without the quotes). Label Separator Labels in a name are separated using the label separator U+002E ("." without the quotes). In GNS, with the exceptions of zone Top-Level Domains (see below) and boxed records Section 5.3.3, every separator label in a name delegates to another zone. Top-Level Domain The rightmost part of a GNS name is a GNS Top-Level Domain (TLD). A GNS TLD may consist of one or more labels. Unlike DNS Top-Level Domains (defined in [RFC8499]), GNS does not expect all users to use the same global root zone. Instead, with the exception of Zone Top-Level Domains (see below), GNS TLDs are typically part of the configuration of the local resolver (see Section 7.1), and may thus not be globally unique. Zone A GNS zone contains authoritative information (resource records). A zone is uniquely identified by its zone key. Unlike DNS zones, a GNS zone does not need to have a SOA record under the apex label. Zone Type The type of a GNS zone determines the cipher system and binary encoding format of the zone key, blinded zone keys, and signatures. Zone Key The zone key uniquely identifies a zone. The zone key is Schanzenbach, et al. Expires 30 August 2022 [Page 5] Internet-Draft The GNU Name System February 2022 usually a public key of an asymmetric key pair. Blinded Zone Key A blinded zone key is derived from the zone key and a label. The zone key and the blinded zone key are unlinkable without knowledge of the label. Zone Key Derivation Function The zone key derivation function (ZKDF) blinds a key using a label. There are different functions for public and private keys, respectively. Zone Owner The owner of a GNS zone is the holder of the secret (typically a private key) that (together with a label and a value to sign) allows the creation of zone signatures that can be validated against the respective blinded zone key. Zone Top-Level Domain A GNS Zone Top-Level Domain (zTLD) is a sequence of GNS labels at the end of a GNS name which encodes a zone type and zone key of a zone. Due to the statistical uniqueness of zone keys, zTLDs are also globally unique. A zTLD label sequence can only be distinguished from ordinary TLD label sequences by attempting to decode the labels into a zone type and zone key. Resource Record A GNS resource record is the information associated with a label in a GNS zone. A GNS resource record contains information as defined by its resource record type. 3. Overview In GNS, any user may create and manage one or more cryptographically secured zones (Section 4). Zones are uniquely identified by a zone key. Zone contents are signed using blinded private keys and encrypted using derived secret keys. The zone type determines the respective set of cryptographic operations and the wire formats for encrypted data, public keys and signatures. A zone can be populated with mappings from labels to resource records by its owner (Section 5). A label can be mapped to a delegation record which results in the corresponding subdomain being delegated to another zone. Circular delegations are explicitly allowed, including delegating a subdomain to its immediate parent zone. In order to support (legacy) applications as well as to facilitate the use of petnames, GNS defines auxiliary record types in addition to supporting existing DNS records. Zone contents are encrypted and signed before being published in a distributed key-value storage (Section 6). In this process, unique zone identification is hidden from the network through the use of key Schanzenbach, et al. Expires 30 August 2022 [Page 6] Internet-Draft The GNU Name System February 2022 blinding. Key blinding allows the creation of signatures for zone contents using a blinded public/private key pair. This blinding is realized using a deterministic key derivation from the original zone key and corresponding private key using record label values as blinding factors. Specifically, the zone owner can derive blinded private keys for each record set published under a label, and a resolver can derive the corresponding blinded public keys. It is expected that GNS implementations use distributed or decentralized storages such as distributed hash tables (DHT) in order to facilitate availability within a network without the need for dedicated infrastructure. Specification of such a distributed or decentralized storage is out of scope of this document, but possible existing implementations include those based on [RFC7363], [Kademlia] or [R5N]. Starting from a configurable start zone, names are resolved by following zone delegations. For each label in a name, the recursive GNS resolver fetches the respective record from the storage layer (Section 7). Without knowledge of the label values and the zone keys, the different derived keys are unlinkable both to the original zone key and to each other. This prevents zone enumeration (except via impractical online brute force attacks) and requires knowledge of both the zone key and the label to confirm affiliation of a query or the corresponding encrypted record set with a specific zone. At the same time, the blinded zone key provides resolvers with the ability to verify the integrity of the published information without disclosing the originating zone. In the remainder of this document, the "implementer" refers to the developer building a GNS implementation including, for example, zone management tools and name resolution components. 4. Zones An implementation SHOULD enable the user to create and manage zones. If this functionality is not implemented, names can still be resolved if zone keys for the initial step in the name resolution are available (see Section 7). A zone in GNS is uniquely identified by its zone type and zone key. Each zone can be represented by a Zone Top-Level Domain (zTLD) string. A zone type (ztype) is a unique 32-bit number. This number corresponds to a resource record type number identifying a delegation record type in the GNUnet Assigned Numbers Authority [GANA]. The ztype determines which cryptosystem is used for the asymmetric and symmetric key operations of the zone and the format of the delegation record type. Any ztype MUST define the following set of cryptographic functions: Schanzenbach, et al. Expires 30 August 2022 [Page 7] Internet-Draft The GNU Name System February 2022 KeyGen() -> d, zk is a function to generate a new private key d and the corresponding public zone key zk. ZKDF-Private(d,label) -> d' is a zone key derivation function which blinds a private key d using label, resulting in another private key which can be used to create cryptographic signatures. GNS only requires a signature to be created directly with d to sign a revocation message for the zone key zk. ZKDF-Public(zk,label) -> zk' is a zone key derivation function which blinds a zone key zk using a label. zk and zk' must be unlinkable. Furthermore, blinding zk with different values for the label must result in different, unlinkable zk' values. S-Encrypt(zk,label,expiration,message) -> ciphertext is a symmetric encryption function which encrypts the record data based on key material derived from the zone key, a label, and an expiration timestamp. In order to leverage performance-enhancing caching features of certain underlying storages, in particular DHTs, a deterministic encryption scheme is recommended. S-Decrypt(zk,label,expiration,ciphertext) -> message is a symmetric decryption function which decrypts the encrypted record data based on key material derived from the zone key, a label, and an expiration timestamp. Sign(d,message) -> signature is a function to sign a message (typically encrypted record data) using the private key d, yielding an unforgeable cryptographic signature. In order to leverage performance-enhancing caching features of certain underlying storages, in particular DHTs, a deterministic signature scheme is recommended. Verify(zk,message,signature) -> boolean is a function to verify the signature was created using the private key d corresponding to the zone key zk where d,zk := Keygen(). The function returns a boolean value of "TRUE" if the signature is valid, and otherwise "FALSE". SignDerived(d,label,message) -> signature is a function to sign a message (typically encrypted record data) that can be verified using the derived zone key zk' := ZKDF-Public(zk,label). In order to leverage performance-enhancing caching features of certain underlying storages, in particular DHTs, a deterministic signature scheme is recommended. VerifyDerived(zk,label,message,signature) -> boolean is function to Schanzenbach, et al. Expires 30 August 2022 [Page 8] Internet-Draft The GNU Name System February 2022 verify the signature using the derived zone key zk' := ZKDF- Public(zk,label). The function returns a boolean value of "TRUE" if the signature is valid, and otherwise "FALSE". The cryptographic functions of the default ztypes are specified with their corresponding delegation records in Section 5.1. New ztypes may be specified in the future, for example if the cryptographic mechanisms used in this document are broken. 4.1. Zone Top-Level Domain The zTLD is the Zone Top-Level Domain. It is a string which encodes the zone type and zone key into a domain name. The zTLD is used as a globally unique reference to a specific zone in the process of name resolution. It is created by encoding a binary concatenation of the zone type and zone key (see Figure 1). The used encoding is a variation of the Crockford Base32 encoding [CrockfordB32] called Base32GNS. The encoding and decoding symbols for Base32GNS including this modification are defined in the table found in Figure 21. The functions for encoding and decoding based on this table are called Base32GNS-Encode and Base32GNS-Decode, respectively. 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | ZONE TYPE | ZONE KEY / +-----+-----+-----+-----+ / / / / / Figure 1: The decoded binary representation of the zTLD Consequently, a zTLD is encoded and decoded as follows: zTLD := Base32GNS-Encode(ztype||zkey) ztype||zkey := Base32GNS-Decode(zTLD) Schanzenbach, et al. Expires 30 August 2022 [Page 9] Internet-Draft The GNU Name System February 2022 The zTLD can be used as-is as a rightmost label in a GNS name. If an application wants to ensure DNS compatibility of the name, it MAY also represent the zTLD as follows: If the zTLD is less than or equal to 63 characters, it can be used as a zTLD as-is. If the zTLD is longer than 63 characters, the zTLD is divided into smaller labels separated by the label separator. Here, the most significant bytes of the "ztype||zkey" concatenation must be contained in the rightmost label of the resulting string and the least significant bytes in the leftmost label of the resulting string. This allows the resolver to determine the ztype and zTLD length from the rightmost label and to subsequently determine how many labels the zTLD should span. A GNS implementation MUST support the division of zTLD in DNS compatible label lengths. For example, assuming a zTLD of 130 characters, the division is: zTLD[126..129].zTLD[63..125].zTLD[0..62] 4.2. Zone Revocation In order to revoke a zone key, a signed revocation message MUST be published. This message MUST be signed using the private key. The revocation message is broadcast to the network. The specification of the broadcast mechanism is out of scope for this document. A possible broadcast mechanism for efficient flooding in a distributed network is implemented in [GNUnet]. Alternatively, revocation messages could also be distributed via a distributed ledger or a trusted central server. To prevent flooding attacks, the revocation message MUST contain a proof of work (PoW). The revocation message including the PoW MAY be calculated ahead of time to support timely revocation. For all occurrences below, "Argon2id" is the Password-based Key Derivation Function as defined in [RFC9106]. For the PoW calculations the algorithm is instantiated with the following parameters: S The salt. Fixed 16-byte string: "GnsRevocationPow". t Number of iterations: 3 m Memory size in KiB: 1024 T Output length of hash in bytes: 64 p Parallelization parameter: 1 v Algorithm version: 0x13 Schanzenbach, et al. Expires 30 August 2022 [Page 10] Internet-Draft The GNU Name System February 2022 y Algorithm type (Argon2id): 2 X Unused K Unused Figure 2 illustrates the format of the data "P" on which the PoW is calculated. 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | POW | +-----------------------------------------------+ | TIMESTAMP | +-----------------------------------------------+ | ZONE TYPE | ZONE KEY | +-----+-----+-----+-----+ | / / / / +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 2: The Format of the PoW Data. POW A 64-bit value that is a solution to the PoW. In network byte order. TIMESTAMP denotes the absolute 64-bit date when the revocation was computed. In microseconds since midnight (0 hour), January 1, 1970 UTC in network byte order. ZONE TYPE is the 32-bit zone type. ZONE KEY is the 256-bit public key zk of the zone which is being revoked. The wire format of this value is defined by the ZONE TYPE. Usually, PoW schemes require to find one POW value such that at least D leading zeroes are found in the hash result. D is then referred to as the difficulty of the PoW. In order to reduce the variance in time it takes to calculate the PoW, a valid GNS revocation requires that a number Z different PoWs must be found that on average have D leading zeroes. Schanzenbach, et al. Expires 30 August 2022 [Page 11] Internet-Draft The GNU Name System February 2022 The resulting proofs may then published and disseminated. The concrete dissemination and publication methods are out of scope of this document. Given an average difficulty of D, the proofs have an expiration time of EPOCH. With each additional bit difficulty, the lifetime of the proof is prolonged for another EPOCH. Consequently, by calculating a more difficult PoW, the lifetime of the proof can be increased on demand by the zone owner. The parameters are defined as follows: Z The number of PoWs required is fixed at 32. D The minimum average difficulty is fixed at 22. EPOCH A single epoch is fixed at 365 days. The revocation message wire format is illustrated in Figure 3. 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | TIMESTAMP | +-----+-----+-----+-----+-----+-----+-----+-----+ | TTL | +-----+-----+-----+-----+-----+-----+-----+-----+ | POW_0 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ... | +-----+-----+-----+-----+-----+-----+-----+-----+ | POW_Z-1 | +-----------------------------------------------+ | ZONE TYPE | ZONE KEY | +-----+-----+-----+-----+ | / / / / +-----+-----+-----+-----+-----+-----+-----+-----+ | SIGNATURE | / / / / | | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 3: The Revocation Message Wire Format. TIMESTAMP denotes the absolute 64-bit date when the revocation was computed. In microseconds since midnight (0 hour), January 1, 1970 UTC in network byte order. This is the same value as the time stamp used in the individual PoW calculations. Schanzenbach, et al. Expires 30 August 2022 [Page 12] Internet-Draft The GNU Name System February 2022 TTL denotes the relative 64-bit time to live of the record in microseconds also in network byte order. The field SHOULD be set to EPOCH * 1.1. Given an average number of leading zeros D', then the field value MAY be increased up to (D'-D) * EPOCH * 1.1. Lower or higher values may result in rejection of the revocation message when broadcast. The EPOCH is extended by 10% in order to deal with unsynchronized clocks. POW_i The values calculated as part of the PoW, in network byte order. Each POW_i MUST be unique in the set of POW values. To facilitate fast verification of uniqueness, the POW values must be given in strictly monotonically increasing order in the message. ZONE TYPE The 32-bit zone type corresponding to the zone key. ZONE KEY is the public key zk of the zone which is being revoked and the key to be used to verify SIGNATURE. SIGNATURE A signature over a time stamp and the zone zk of the zone which is revoked and corresponds to the key used in the PoW. The signature is created using the Sign() function of the cryptosystem of the zone and the private key (see Section 4). The signature over the public key covers a 32-bit header prefixed to the time stamp and public key fields. The header includes the key length and signature purpose. The wire format is illustrated in Figure 4. 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | SIZE | PURPOSE (0x03) | +-----+-----+-----+-----+-----+-----+-----+-----+ | TIMESTAMP | +-----+-----+-----+-----+-----+-----+-----+-----+ | ZONE TYPE | ZONE KEY | +-----+-----+-----+-----+ | / / / / +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 4: The Wire Format of the Revocation Data for Signing. SIZE A 32-bit value containing the length of the signed data in bytes in network byte order. PURPOSE A 32-bit signature purpose flag. The value of this field Schanzenbach, et al. Expires 30 August 2022 [Page 13] Internet-Draft The GNU Name System February 2022 MUST be 3. The value is encoded in network byte order. It defines the context in which the signature is created so that it cannot be reused in other parts of the protocol including possible future extensions. The value of this field corresponds to an entry in the GANA "GNUnet Signature Purpose" registry Section 10. TIMESTAMP Field as defined in the revocation message above. ZONE TYPE Field as defined in the revocation message above. ZONE KEY Field as defined in the revocation message above. In order to validate a revocation the following steps MUST be taken: 1. The signature MUST be verified against the zone key. 2. The set of POW values MUST NOT contain duplicates which MUST be checked by verifying that the values are strictly monotonically increasing. 3. The average number of leading zeroes D' resulting from the provided POW values MUST be greater than and not equal to D. Implementers MUST NOT use an integer data type to calculate or represent D'. The TTL field in the revocation message is informational. A revocation MAY be discarded without checking the POW values or the signature if the TTL (in combination with TIMESTAMP) indicates that the revocation has already expired. The actual validity period of the revocation MUST be determined by examining the leading zeroes in the POW values. The validity period of the revocation is calculated as (D'-D) * EPOCH * 1.1. The EPOCH is extended by 10% in order to deal with unsynchronized clocks. The validity period added on top of the TIMESTAMP yields the expiration date. If the current time is after the expiration date, the revocation is considered stale but may still be otherwise considered valid. Verified revocations MUST be stored locally. The implementation MAY discard stale revocations and evict then from the local store at any time. Schanzenbach, et al. Expires 30 August 2022 [Page 14] Internet-Draft The GNU Name System February 2022 Implementations MUST broadcast received revocations to if they are valid and not stale. Should the calculated validity period differ from the TTL field value, the calculated value MUST be used as TTL field value when forwarding the revocation message. Systems may disagree on the current time, so implementations MAY use stale but otherwise valid revocations but SHOULD NOT broadcast them. Forwarded stale revocations may be discarded. Any locally stored revocation MUST be considered during delegation record processing (Section 7.3.4). 5. Resource Records A GNS implementation SHOULD provide a mechanism to create and manage local zones as well as a persistence mechanism such as a database for resource records. A new local zone is established by selecting a zone type and creating a zone key pair. If this mechanism is not implemented, no zones can be published in the storage (Section 6) and name resolution is limited to non-local start zones (Section 7.1). A GNS resource record holds the data of a specific record in a zone. The resource record format is defined in Figure 5. 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | EXPIRATION | +-----+-----+-----+-----+-----+-----+-----+-----+ | SIZE | FLAGS | TYPE | +-----+-----+-----+-----+-----+-----+-----+-----+ | DATA / / / / / Figure 5: The Resource Record Wire Format. EXPIRATION denotes the absolute 64-bit expiration date of the record. In microseconds since midnight (0 hour), January 1, 1970 UTC in network byte order. SIZE denotes the 16-bit size of the DATA field in bytes and in network byte order. FLAGS is a 16-bit resource record flags field (see below). TYPE is the 32-bit resource record type. This type can be one of the GNS resource records as defined in Section 5 or a DNS record type as defined in [RFC1035] or any of the complementary standardized DNS resource record types. This value must be stored Schanzenbach, et al. Expires 30 August 2022 [Page 15] Internet-Draft The GNU Name System February 2022 in network byte order. Note that values below 2^16 are reserved for allocation via IANA [RFC6895], while values above 2^16 are allocated by the GNUnet Assigned Numbers Authority [GANA]. DATA the variable-length resource record data payload. The content is defined by the respective type of the resource record. Flags indicate metadata surrounding the resource record. An application creating resource records MUST set all bits to 0 unless it wants to set the respective flag. Additional flags may be defined in future protocol versions, If an application or implementation encounters a flag which it does not recognize, it MUST be ignored. Any combination of the flags specified below are valid. Figure 6 illustrates the flag distribution in the 16-bit flag field of a resource record: 0 13 14 15 +--------...+-------------+-------+---------+ | Reserved |SUPPLEMENTAL |SHADOW |CRITICAL | +--------...+-------------+-------+---------+ Figure 6: The Resource Record Flag Wire Format. CRITICAL If this flag is set, it indicates that processing is critical. Implementations that do not support the record type or are otherwise unable to process the record MUST abort resolution upon encountering the record in the resolution process. SHADOW If this flag is set, this record MUST be ignored by resolvers unless all (other) records of the same record type have expired. Used to allow zone publishers to facilitate good performance when records change by allowing them to put future values of records into the storage. This way, future values can propagate and may be cached before the transition becomes active. SUPPLEMENTAL This is a supplemental record. It is provided in addition to the other records. This flag indicates that this record is not explicitly managed alongside the other records under the respective name but may be useful for the application. 5.1. Zone Delegation Records This section defines the initial set of zone delegation record types. Any implementation SHOULD support all zone types defined here and MAY support any number of additional delegation records defined in the GNU Name System Record Types registry (see Section 10). Not supporting some zone types will result in resolution failures in case the respective zone type is encountered. This may be a valid choice Schanzenbach, et al. Expires 30 August 2022 [Page 16] Internet-Draft The GNU Name System February 2022 if some zone delegation record types have been determined to be cryptographically insecure. Zone delegation records MUST NOT be stored and published under the apex label. A zone delegation record type value is the same as the respective ztype value. The ztype defines the cryptographic primitives for the zone that is being delegated to. A zone delegation record payload contains the public key of the zone to delegate to. A zone delegation record MUST have the CRTITICAL flag set and MUST be the only non-supplemental record under a label. There MAY be inactive records of the same type which have the SHADOW flag set in order to facilitate smooth key rollovers. flag set No other records are allowed. 5.1.1. PKEY In GNS, a delegation of a label to a zone of type "PKEY" is represented through a PKEY record. The PKEY DATA entry wire format can be found in Figure 7. 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | PUBLIC KEY | | | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 7: The PKEY Wire Format. PUBLIC KEY A 256-bit Ed25519 public key. For PKEY zones the zone key material is derived using the curve parameters of the twisted Edwards representation of Curve25519 [RFC7748] (a.k.a. Ed25519) with the ECDSA scheme [RFC6979]. The following naming convention is used for the cryptographic primitives of PKEY zones: d is a 256-bit Ed25519 private key (private scalar). zk is the Ed25519 public zone key corresponding to d. p is the prime of edwards25519 as defined in [RFC7748], i.e. 2^255 - 19. G is the group generator (X(P),Y(P)) of edwards25519 as defined in [RFC7748]. L is the order of the prime-order subgroup of edwards25519 in [RFC7748]. Schanzenbach, et al. Expires 30 August 2022 [Page 17] Internet-Draft The GNU Name System February 2022 KeyGen() The generation of the private scalar d and the curve point zk := d*G (where G is the group generator of the elliptic curve) as defined in Section 2.2. of [RFC6979] represents the KeyGen() function. The zone type and zone key of a PKEY are 4 + 32 bytes in length. This means that a zTLD will always fit into a single label and does not need any further conversion. Given a label, the output d' of the ZKDF-Private(d,label) function for zone key blinding is calculated as follows for PKEY zones: ZKDF-Private(d,label): zk := d * G PRK_h := HKDF-Extract ("key-derivation", zk) h := HKDF-Expand (PRK_h, label || "gns", 512 / 8) d' := (h * d) mod L return d' Equally, given a label, the output zk' of the ZKDF-Public(zk,label) function is calculated as follows for PKEY zones: ZKDF-Public(zk,label): PRK_h := HKDF-Extract ("key-derivation", zk) h := HKDF-Expand (PRK_h, label || "gns", 512 / 8) zk' := (h mod L) * zk return zk' The PKEY cryptosystem uses a hash-based key derivation function (HKDF) as defined in [RFC5869], using SHA-512 [RFC6234] for the extraction phase and SHA-256 [RFC6234] for the expansion phase. PRK_h is key material retrieved using an HKDF using the string "key- derivation" as salt and the zone key as initial keying material. h is the 512-bit HKDF expansion result and must be interpreted in network byte order. The expansion information input is a concatenation of the label and the string "gns". The multiplication of zk with h is a point multiplication, while the multiplication of d with h is a scalar multiplication. The Sign() and Verify() functions for PKEY zones are implemented using 512-bit ECDSA deterministic signatures as specified in [RFC6979]. The same functions can be used for derived keys: SignDerived(d,label,message): d' := ZKDF-Private(d,label) return Sign(d',message) A signature (R,S) is valid if the following holds: Schanzenbach, et al. Expires 30 August 2022 [Page 18] Internet-Draft The GNU Name System February 2022 VerifyDerived(zk,label,message,signature): zk' := ZKDF-Public(zk,label) return Verify(zk',message,signature) The S-Encrypt() and S-Decrypt() functions use AES in counter mode as defined in [MODES] (CTR-AES-256): S-Encrypt(zk,label,expiration,plaintext): PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk) PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk) K := HKDF-Expand (PRK_k, label, 256 / 8) NONCE := HKDF-Expand (PRK_n, label, 32 / 8) IV := NONCE || expiration || 0x0000000000000001 return CTR-AES256(K, IV, plaintext) S-Decrypt(zk,label,expiration,ciphertext): PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk) PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk) K := HKDF-Expand (PRK_k, label, 256 / 8) NONCE := HKDF-Expand (PRK_n, label, 32 / 8) IV := NONCE || expiration || 0x0000000000000001 return CTR-AES256(K, IV, ciphertext) The key K and counter IV are derived from the record label and the zone key zk using a hash-based key derivation function (HDKF) as defined in [RFC5869]. SHA-512 [RFC6234] is used for the extraction phase and SHA-256 [RFC6234] for the expansion phase. The output keying material is 32 bytes (256 bits) for the symmetric key and 4 bytes (32 bits) for the nonce. The symmetric key K is a 256-bit AES [RFC3826] key. The nonce is combined with a 64-bit initialization vector and a 32-bit block counter as defined in [RFC3686]. The block counter begins with the value of 1, and it is incremented to generate subsequent portions of the key stream. The block counter is a 32-bit integer value in network byte order. The initialization vector is the expiration time of the resource record block in network byte order. The resulting counter (IV) wire format can be found in Figure 8. Schanzenbach, et al. Expires 30 August 2022 [Page 19] Internet-Draft The GNU Name System February 2022 0 8 16 24 32 +-----+-----+-----+-----+ | NONCE | +-----+-----+-----+-----+ | EXPIRATION | | | +-----+-----+-----+-----+ | BLOCK COUNTER | +-----+-----+-----+-----+ Figure 8: The Block Counter Wire Format. 5.1.2. EDKEY In GNS, a delegation of a label to a zone of type "EDKEY" is represented through a EDKEY record. The EDKEY DATA entry wire format is illustrated in Figure 9. 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | PUBLIC KEY | | | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 9: The EDKEY DATA Wire Format. PUBLIC KEY A 256-bit EdDSA zone key. For EDKEY zones the zone key material is derived using the curve parameters of the twisted edwards representation of Curve25519 [RFC7748] (a.k.a. Ed25519) with the Ed25519 scheme [ed25519] as specified in [RFC8032]. The following naming convention is used for the cryptographic primitives of EDKEY zones: d is a 256-bit EdDSA private key. a is is an integer derived from d using the SHA-512 hash function as defined in [RFC8032]. zk is the EdDSA public key corresponding to d. It is defined as the curve point a*G where G is the group generator of the elliptic curve as defined in [RFC8032]. p is the prime of edwards25519 as defined in [RFC8032], i.e. 2^255 - 19. Schanzenbach, et al. Expires 30 August 2022 [Page 20] Internet-Draft The GNU Name System February 2022 G is the group generator (X(P),Y(P)) of edwards25519 as defined in [RFC8032]. L is the order of the prime-order subgroup of edwards25519 in [RFC8032]. KeyGen() The generation of the private key d and the associated public key zk := a*G where G is the group generator of the elliptic curve and a is an integer derived from d using the SHA-512 hash function as defined in Section 5.1.5 of [RFC8032] represents the KeyGen() function. The zone type and zone key of an EDKEY are 4 + 32 bytes in length. This means that a zTLD will always fit into a single label and does not need any further conversion. The "EDKEY" ZKDF instantiation is based on [Tor224]. The calculation of a is defined in Section 5.1.5 of [RFC8032]. Given a label, the output of the ZKDF-Private function for zone key blinding is calculated as follows for EDKEY zones: ZKDF-Private(d,label): /* EdDSA clamping */ a := SHA-512 (d) a[0] &= 248 a[31] &= 127 a[31] |= 64 /* Calculate zk from d */ zk := a * G /* Calculate the blinding factor */ PRK_h := HKDF-Extract ("key-derivation", zk) h := HKDF-Expand (PRK_h, label || "gns", 512 / 8) /* Ensure that h == h mod L */ h[31] &= 7 a1 := a >> 3 a2 := (h * a1) mod L d' := a2 << 3 return d' Equally, given a label, the output of the ZKDF-Public function is calculated as follows for PKEY zones: Schanzenbach, et al. Expires 30 August 2022 [Page 21] Internet-Draft The GNU Name System February 2022 ZKDF-Public(zk,label): /* Calculate the blinding factor */ PRK_h := HKDF-Extract ("key-derivation", zk) h := HKDF-Expand (PRK_h, label || "gns", 512 / 8) /* Ensure that h == h mod L */ h[31] &= 7 zk' := h * zk return zk' Implementers SHOULD employ a constant time scalar multiplication for the constructions above to protect against timing attacks. Otherwise, timing attacks may leak private key material if an attacker can predict when a system starts the publication process. The EDKEY cryptosystem uses a hash-based key derivation function (HKDF) as defined in [RFC5869], using SHA-512 [RFC6234] for the extraction phase and HMAC-SHA256 [RFC6234] for the expansion phase. PRK_h is key material retrieved using an HKDF using the string "key- derivation" as salt and the zone key as initial keying material. The blinding factor h is the 512-bit HKDF expansion result. The expansion information input is a concatenation of the label and the string "gns". The result of the HKDF must be clamped and interpreted in network byte order. a is the 256-bit integer corresponding to the 256-bit private key d. The multiplication of zk with h is a point multiplication, while the division and multiplication of a and a1 with the co-factor are integer operations. The Sign(d,message) and Verify(zk,message,signature) procedures MUST be implemented as defined in [RFC8032]. Signatures for EDKEY zones using the derived private scalar d' are not compliant with [RFC8032]. As the corresponding private key to the derived private scalar d' is not known, it is not possible to deterministically derive the signature part R according to [RFC8032]. Instead, signatures MUST be generated as follows for any given message and private zone key: A nonce is calculated from the highest 32 bytes of the expansion of the private key d and the blinding factor h. The nonce is then hashed with the message to r. This way, the full derivation path is included in the calculation of the R value of the signature, ensuring that it is never reused for two different derivation paths or messages. Schanzenbach, et al. Expires 30 August 2022 [Page 22] Internet-Draft The GNU Name System February 2022 SignDerived(d,label,message): /* EdDSA clamping */ a := SHA-512 (d) a[0] &= 248 a[31] &= 127 a[31] |= 64 /* Calculate zk from d */ zk := a * G /* Calculate blinding factor */ PRK_h := HKDF-Extract ("key-derivation", zk) h := HKDF-Expand (PRK_h, label || "gns", 512 / 8) d' := ZKDF-Private(d,label) dh := SHA-512 (d) nonce := SHA-256 (dh[32..63] || h) r := SHA-512 (nonce || message) R := r * G S := r + SHA-512(R || zk' || message) * d' mod L return (R,S) A signature (R,S) is valid if the following holds: VerifyDerived(zk,label,message,signature): zk' := ZKDF-Public(zk,label) (R,S) := signature return S * G == R + SHA-512(R, zk', message) * zk' The S-Encrypt() and S-Decrypt() functions use XSalsa20 as defined in [XSalsa20] (XSalsa20-Poly1305): S-Encrypt(zk,label,expiration,message): PRK_k := HKDF-Extract ("gns-xsalsa-ctx-key", zk) PRK_n := HKDF-Extract ("gns-xsalsa-ctx-iv", zk) K := HKDF-Expand (PRK_k, label, 256 / 8) NONCE := HKDF-Expand (PRK_n, label, 128 / 8) IV := NONCE || expiration return XSalsa20-Poly1305(K, IV, message) S-Decrypt(zk,label,expiration,ciphertext): PRK_k := HKDF-Extract ("gns-xsalsa-ctx-key", zk) PRK_n := HKDF-Extract ("gns-xsalsa-ctx-iv", zk) K := HKDF-Expand (PRK_k, label, 256 / 8) NONCE := HKDF-Expand (PRK_n, label, 128 / 8) IV := NONCE || expiration return XSalsa20-Poly1305(K, IV, ciphertext) Schanzenbach, et al. Expires 30 August 2022 [Page 23] Internet-Draft The GNU Name System February 2022 The result of the XSalsa20-Poly1305 encryption function is the encrypted ciphertext followed by the 128-bit authentication tag. Accordingly, the length of encrypted data equals the length of the data plus the 16 bytes of the authentication tag. The key K and counter IV are derived from the record label and the zone key zk using a hash-based key derivation function (HKDF) as defined in [RFC5869]. SHA-512 [RFC6234] is used for the extraction phase and SHA-256 [RFC6234] for the expansion phase. The output keying material is 32 bytes (256 bits) for the symmetric key and 16 bytes (128 bits) for the NONCE. The symmetric key K is a 256-bit XSalsa20 [XSalsa20] key. No additional authenticated data (AAD) is used. The nonce is combined with an 8 byte initialization vector. The initialization vector is the expiration time of the resource record block in network byte order. The resulting counter (IV) wire format is illustrated in Figure 10. 0 8 16 24 32 +-----+-----+-----+-----+ | NONCE | | | | | | | +-----+-----+-----+-----+ | EXPIRATION | | | +-----+-----+-----+-----+ Figure 10: The Counter Block Initialization Vector. 5.2. Redirection Records Redirect records may be used to redirect resolution. Any implementation SHOULD support all redirection record types defined here and MAY support any number of additional redirection records defined in the GNU Name System Record Types registry (see Section Section 10). Redirection records MUST have the CRTITICAL flag set. Not supporting some record types may consequently result in resolution failures. This may be a valid choice if some redirection record types have been determined to be insecure, or if an application has reasons to not support redirection to DNS for reasons such as complexity or security. Redirection records MUST NOT be stored and published under the apex label. Schanzenbach, et al. Expires 30 August 2022 [Page 24] Internet-Draft The GNU Name System February 2022 5.2.1. REDIRECT A REDIRECT record is the GNS equivalent of a CNAME record in DNS. A REDIRECT record MUST be the only non-supplemental record under a label. There MAY be inactive records of the same type which have the SHADOW flag set in order to facilitate smooth changes of redirection targets. No other records are allowed. Details on processing of this record is defined in Section 7.3.1. A REDIRECT DATA entry is illustrated in Figure 11. 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | REDIRECT NAME | / / / / | | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 11: The REDIRECT DATA Wire Format. REDIRECT NAME The name to continue with. The value of a redirect record may be a regular name, or a relative name. Relative GNS names are indicated by an extension label (U+002B, "+") as rightmost label. The string is UTF-8 encoded and 0-terminated. 5.2.2. GNS2DNS It is possible to delegate a label back into DNS through a GNS2DNS record. The resource record contains a DNS name for the resolver to continue with in DNS followed by a DNS server. Both names are in the format defined in [RFC1034] for DNS names. There MAY be multiple GNS2DNS records under a label. There MAY also be DNSSEC DS records or any other records used to secure the connection with the DNS servers under the same label. There MAY be inactive records of the same type(s) which have the SHADOW flag set in order to facilitate smooth changes of redirection targets. No other non-supplemental record types are allowed in the same record set. A GNS2DNS DATA entry is illustrated in Figure 12. Schanzenbach, et al. Expires 30 August 2022 [Page 25] Internet-Draft The GNU Name System February 2022 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | DNS NAME | / / / / | | +-----+-----+-----+-----+-----+-----+-----+-----+ | DNS SERVER NAME | / / / / | | +-----------------------------------------------+ Figure 12: The GNS2DNS DATA Wire Format. DNS NAME The name to continue with in DNS. The value is UTF-8 encoded and 0-terminated. DNS SERVER NAME The DNS server to use. May be an IPv4 address in dotted-decimal form or an IPv6 address in colon-hexadecimal form or a DNS name. It may also be a relative GNS name ending with a "+" as the rightmost label. The implementation MUST check the string syntactically for an IP address in the respective notation before checking for a relative GNS name. If all three checks fail, the name MUST be treated as a DNS name. The value is UTF-8 encoded and 0-terminated. NOTE: If an application uses DNS names obtained from GNS2DNS records in a DNS request they MUST first be converted to an IDNA compliant representation [RFC5890]. 5.3. Auxiliary Records This section defines the initial set of auxiliary GNS record types. Any implementation SHOULD be able to process the specified record types according to Section 7.3. 5.3.1. LEHO This record is used to provide a hint for LEgacy HOstnames: Applications can use the GNS to lookup IPv4 or IPv6 addresses of internet services. However, sometimes connecting to such services does not only require the knowledge of an address and port, but also requires the canonical DNS name of the service to be transmitted over the transport protocol. In GNS, legacy host name records provide applications the DNS name that is required to establish a connection to such a service. The most common use case is HTTP virtual hosting, where a DNS name must be supplied in the HTTP "Host"-header. Using a Schanzenbach, et al. Expires 30 August 2022 [Page 26] Internet-Draft The GNU Name System February 2022 GNS name for the "Host"-header may not work as it may not be globally unique. Furthermore, even if uniqueness is not an issue, the legacy service might not even be aware of GNS. A LEHO resource record is expected to be found together in a single resource record with an IPv4 or IPv6 address. A LEHO DATA entry is illustrated in Figure 13. 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | LEGACY HOSTNAME | / / / / | | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 13: The LEHO DATA Wire Format. LEGACY HOSTNAME A UTF-8 string (which is not 0-terminated) representing the legacy hostname. NOTE: If an application uses a LEHO value in an HTTP request header (e.g. "Host:" header) it MUST be converted to an IDNA compliant representation [RFC5890]. 5.3.2. NICK Nickname records can be used by zone administrators to publish a label that a zone prefers to have used when it is referred to. This is a suggestion to other zones what label to use when creating a delegation record (Section 5.1) containing this zone key. This record SHOULD only be stored under the apex label "@" but MAY be returned with record sets under any label as a supplemental record. Section 7.3.5 details how a resolver must process supplemental and non-supplemental NICK records. A NICK DATA entry is illustrated in Figure 14. 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | NICKNAME | / / / / | | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 14: The NICK DATA Wire Format. NICKNAME A UTF-8 string (which is not 0-terminated) representing the Schanzenbach, et al. Expires 30 August 2022 [Page 27] Internet-Draft The GNU Name System February 2022 preferred label of the zone. This string MUST be a valid GNS label. 5.3.3. BOX GNS lookups are expected to return all of the required useful information in one record set. This avoids unnecessary additional lookups and cryptographically ties together information that belongs together, making it impossible for an adversarial storage to provide partial answers that might omit information critical for security. This general strategy is incompatible with the special labels used by DNS for SRV and TLSA records. Thus, GNS defines the BOX record format to box up SRV and TLSA records and include them in the record set of the label they are associated with. For example, a TLSA record for "_https._tcp.example.org" will be stored in the record set of "example.org" as a BOX record with service (SVC) 443 (https) and protocol (PROTO) 6 (tcp) and record TYPE "TLSA". For reference, see also [RFC2782]. A BOX DATA entry is illustrated in Figure 15. 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | PROTO | SVC | TYPE | +-----------+-----------------------------------+ | RECORD DATA | / / / / | | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 15: The BOX DATA Wire Format. PROTO the 16-bit protocol number, e.g. 6 for TCP. Note that values below 2^8 are reserved for allocation via IANA [RFC5237], while values above 2^8 are allocated by the GNUnet Assigned Numbers Authority [GANA]. In network byte order. SVC the 16-bit service value of the boxed record. In case of TCP and UDP it is the port number. In network byte order. TYPE is the 32-bit record type of the boxed record. In network byte order. RECORD DATA is a variable length field containing the "DATA" format of TYPE as defined for the respective TYPE in DNS. Schanzenbach, et al. Expires 30 August 2022 [Page 28] Internet-Draft The GNU Name System February 2022 6. Record Storage Any API which allows storing a value under a 512-bit key and retrieving one or more values from the key can be used by an implementation for record storage. To be useful, the API MUST permit storing at least 176 byte values to be able to support the defined zone delegation record encodings, and SHOULD allow at least 1024 byte values. In the following, it is assumed that an implementation realizes two procedures on top of a storage: PUT(key,value) GET(key) -> value There is no explicit delete function as the deletion of a non-expired record would require a revocation of the record. In GNS, zones can only be revoked as a whole. Records automatically expire and it is under the discretion of the storage as to when to delete the record. The GNS implementation MUST NOT publish expired resource records. Any GNS resolver MUST discard expired records returned from the storage. Resource records are grouped by their respective labels, encrypted and published together in a single resource records block (RRBLOCK) in the storage under a key q: PUT(q, RRBLOCK). The key q is derived from the zone key and the respective label of the contained records. The required knowledge of both zone key and label in combination with the similarly derived symmetric secret keys and blinded zone keys ensure query privacy (see [RFC8324], Section 3.5). The storage key derivation and records block creation is specified in the following sections. The implementation MUST use the PUT storage procedure in order to update the zone contents accordingly. 6.1. The Storage Key Given a label, the storage key q is derived as follows: q := SHA-512 (ZKDF-Public(zk, label)) label is a UTF-8 string under which the resource records are published. zk is the zone key. q Is the 512-bit storage key under which the resource records block is published. It is the SHA-512 hash [RFC6234] over the derived zone key. Schanzenbach, et al. Expires 30 August 2022 [Page 29] Internet-Draft The GNU Name System February 2022 6.2. The Records Block GNS records are grouped by their labels and published as a single block in the storage. The grouped record sets MAY be paired with any number of supplemental records. Supplemental records MUST have the supplemental flag set (See Section 5). The contained resource records are encrypted using a symmetric encryption scheme. A GNS implementation publishes RRBLOCKs in accordance to the properties and recommendations of the underlying storage. This may include a periodic refresh operation to ensure the availability of the published RRBLOCKs. The GNS RRBLOCK wire format is illustrated in Figure 16. 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | SIZE | ZONE TYPE | +-----+-----+-----+-----+-----+-----+-----+-----+ / ZONE KEY / / (BLINDED) / | | +-----+-----+-----+-----+-----+-----+-----+-----+ | SIGNATURE | / / / / | | +-----+-----+-----+-----+-----+-----+-----+-----+ | EXPIRATION | +-----+-----+-----+-----+-----+-----+-----+-----+ | BDATA / / / / | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 16: The RRBLOCK Wire Format. SIZE A 32-bit value containing the length of the block in bytes. In network byte order. While a 32-bit value is used, implementations MAY refuse to publish blocks beyond a certain size significantly below 4 GB. ZONE TYPE is the 32-bit ztype. In network byte order. ZONE KEY is the blinded zone key "ZKDF-Public(zk, label)" to be used to verify SIGNATURE. The length and format of the public key depends on the ztype. SIGNATURE The signature is computed over the EXPIRATION and BDATA Schanzenbach, et al. Expires 30 August 2022 [Page 30] Internet-Draft The GNU Name System February 2022 fields as detailed in Figure 17. The length and format of the signature depends on the ztype. The signature is created using the Sign() function of the cryptosystem of the zone and the derived private key "ZKDF-Private(d, label)" (see Section 4). EXPIRATION Specifies when the RRBLOCK expires and the encrypted block SHOULD be removed from the storage and caches as it is likely stale. However, applications MAY continue to use non- expired individual records until they expire. The value MUST be set to the expiration time of the resource record contained within this block with the smallest expiration time. If a records block includes shadow records, then the maximum expiration time of all shadow records with matching type and the expiration times of the non-shadow records is considered. This is a 64-bit absolute date in microseconds since midnight (0 hour), January 1, 1970 UTC in network byte order. BDATA The encrypted RDATA. Its size is determined by the S-Encrypt() function of the ztype. The signature over the public key covers a 32-bit pseudo header conceptually prefixed to the EXPIRATION and the BDATA fields. The wire format is illustrated in Figure 17. 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | SIZE | PURPOSE (0x0F) | +-----+-----+-----+-----+-----+-----+-----+-----+ | EXPIRATION | +-----+-----+-----+-----+-----+-----+-----+-----+ | BDATA | / / / / +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 17: The Wire Format used for creating the signature of the RRBLOCK. SIZE A 32-bit value containing the length of the signed data in bytes in network byte order. PURPOSE A 32-bit signature purpose flag. The value of this field MUST be 15. The value is encoded in network byte order. It defines the context in which the signature is created so that it cannot be reused in other parts of the protocol including possible future extensions. The value of this field corresponds to an entry in the GANA "GNUnet Signature Purpose" registry Section 10. Schanzenbach, et al. Expires 30 August 2022 [Page 31] Internet-Draft The GNU Name System February 2022 EXPIRATION Field as defined in the RRBLOCK message above. BDATA Field as defined in the RRBLOCK message above. A symmetric encryption scheme is used to encrypt the resource records set RDATA into the BDATA field of a GNS RRBLOCK. The wire format of the RDATA is illustrated in Figure 18. 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | EXPIRATION | +-----+-----+-----+-----+-----+-----+-----+-----+ | SIZE | FLAGS | TYPE | +-----+-----+-----+-----+-----+-----+-----+-----+ | DATA / / / / / +-----+-----+-----+-----+-----+-----+-----+-----+ | EXPIRATION | +-----+-----+-----+-----+-----+-----+-----+-----+ | SIZE | FLAGS | TYPE | +-----+-----+-----+-----+-----+-----+-----+-----+ | DATA / / / +-----+-----+-----+-----+-----+-----+-----+-----+ / PADDING / / / Figure 18: The RDATA Wire Format. EXPIRATION, SIZE, TYPE, FLAGS and DATA These fields were defined in the resource record format in Section 5. PADDING When publishing an RDATA block, the implementation MUST ensure that the size of the RDATA is a power of two using the padding field. The field MUST be set to zero and MUST be ignored on receipt. As a special exception, record sets with (only) a zone delegation record type are never padded. Note that a record set with a delegation record MUST NOT contain other records. If other records are encountered, the whole record block MUST be discarded. Schanzenbach, et al. Expires 30 August 2022 [Page 32] Internet-Draft The GNU Name System February 2022 7. Name Resolution Names in GNS are resolved by recursively querying the record storage. Recursive in this context means that a resolver does not provide intermediate results for a query. Instead, it MUST respond to a resolution request with either the requested resource record or an error message in case the resolution fails. The following sections detail how resolution is initiated and each iteration in the resolution is processed. The application MAY provide a desired record type to the resolver. The desired record type is used to guide processing. For example, if a zone delegation record type is requested, the resolution of the apex label in that zone must be skipped, as the desired record is already found. The resolver implementation MUST NOT filter results according to the desired record type. Filtering of record sets is typically done by the application. 7.1. Start Zones The resolution of a GNS name starts by identifying the start zone suffix. Once the start zone suffix is identified, recursive resolution of the remainder of the name is initiated (Section 7.2). There are two types of start zone suffixes: zTLDs and local suffix- to-zone mappings. The choice of available suffix-to-zone mappings is at the sole discretion of the local system administrator or user. This property addresses the issue of a single hierarchy with a centrally controlled root and the related issue of distribution and management of root servers in DNS (see [RFC8324], Section 3.10 and 3.12). For names ending with a zTLD the start zone is explicitly given in the suffix of the name to resolve. In order to ensure uniqueness of names with zTLDs any implementation MUST use the given zone as start zone. An implementation MUST first try to interpret the rightmost label of the given name as the beginning of a zTLD (Section 4.1). If the rightmost label cannot be (partially) decoded or if it does not indicate a supported ztype, the name is treated as a normal name and start zone discovery MUST continue with finding a local suffix-to- zone mapping. If a valid ztype can be found in the rightmost label, the implementation MUST try to synthesize and decode the zTLD to retrieve the start zone key according to Section 4.1. If the zTLD cannot be synthesized or decoded, the resolution of the name fails and an error is returned to the application. Otherwise, the zone key MUST be used as the start zone: Schanzenbach, et al. Expires 30 August 2022 [Page 33] Internet-Draft The GNU Name System February 2022 Example name: www.example. => Start zone: zk of type ztype => Name to resolve from start zone: www.example For names not ending with a zTLD the resolver MUST determine the start zone through a local suffix-to-zone mapping. Suffix-to-zone mappings MUST be configurable through a local configuration file or database by the user or system administrator. A suffix MAY consist of multiple GNS labels concatenated with a label separator. If multiple suffixes match the name to resolve, the longest matching suffix MUST be used. The suffix length of two results MUST NOT be equal. This indicates a misconfiguration and the implementation MUST return an error. The following is a non-normative example mapping of start zones: Example name: www.example.org Local suffix mappings: org = zTLD0 := Base32GNS(ztype0||zk0) example.org = zTLD1 := Base32GNS(ztype1||zk1) example.com = zTLD2 := Base32GNS(ztype2||zk2) ... => Start zone: zk1 => Name to resolve from start zone: www The process given above MAY be supplemented with other mechanisms if the particular application requires a different process. If no start zone can be discovered, resolution MUST fail and an error MUST be returned to the application. 7.2. Recursion In each step of the recursive name resolution, there is an authoritative zone zk and a name to resolve. The name may be empty. Initially, the authoritative zone is the start zone. If the name is empty, it is interpreted as the apex label "@". From here, the following steps are recursively executed, in order: 1. Extract the right-most label from the name to look up. 2. Calculate q using the label and zk as defined in Section 6.1. 3. Perform a storage query GET(q) to retrieve the RRBLOCK. 4. Verify and process the RRBLOCK and decrypt the BDATA contained in it as defined in Section 6.2. Schanzenbach, et al. Expires 30 August 2022 [Page 34] Internet-Draft The GNU Name System February 2022 Upon receiving the RRBLOCK from the storage, as part of verifying the provided signature, the resolver MUST check that the SHA-512 hash of the derived authoritative zone key zk' from the RRBLOCK matches the query q and that the block is not yet expired. If the signature does not match or the block is expired, the RRBLOCK MUST be ignored and, if applicable, the storage lookup GET(q) MUST continue to look for other RRBLOCKs. 7.3. Record Processing Record processing occurs once a well-formed block has been decrypted. In record processing, only the valid records obtained are considered. To filter records by validity, the resolver MUST at least check the expiration time and the FLAGS field of the respective record. In particular, SHADOW and SUPPLEMENTAL flags may exclude the record from being considered. If the resolver encounters a record with the CRITICAL flag set and does not support the record type the resolution MUST be aborted and an error MUST be returned. The information that the critical record could not be processed SHOULD be returned in the error description. The implementation MAY choose not to return the reason for the failure, merely complicating troubleshooting for the user. The next steps depend on the context of the name that is beging resolved: * Case 1: If the filtered record set consists of a single REDIRECT record, the remainder of the name is prepended to the REDIRECT data and the recursion is started again from the resulting name. Details are described in Section 7.3.1. * Case 2: If the filtered record set consists exclusively of one or more GNS2DNS records resolution continues with DNS. Details are described in Section 7.3.2. * Case 3: If the remainder of the name to be resolved is of the format "_SERVICE._PROTO" and the record set contains one or more matching BOX records, the records in the BOX records are the final result and the recursion is concluded as described in Section 7.3.3. * Case 4: If the current record set consist of a single delegation record, resolution of the remainder of the name is delegated to the target zone as described in Section 7.3.4. * Case 5: If the remainder of the name to resolve is empty the record set is the final result. If any NICK records are in the final result set, it MUST be processed according to Section 7.3.5. Otherwise, the final result set is returned. Schanzenbach, et al. Expires 30 August 2022 [Page 35] Internet-Draft The GNU Name System February 2022 * Finally, if none of the above is applicable resolution fails and the resolver MUST return an empty record set. 7.3.1. REDIRECT If the remaining name is empty and the desired record type is REDIRECT, in which case the resolution concludes with the REDIRECT record. If the rightmost label of the redirect name is the extension label (U+002B, "+"), resolution continues in GNS with the new name in the current zone. Otherwise, the resulting name is resolved via the default operating system name resolution process. This may in turn trigger a GNS name resolution process depending on the system configuration. In case resolution continues in DNS, the name MUST first be converted to an IDNA compliant representation [RFC5890]. In order to prevent infinite loops, the resolver MUST implement loop detections or limit the number of recursive resolution steps. The loop detection MUST be effective even if a REDIRECT found in GNS triggers subsequent GNS lookups via the default operating system name resolution process. 7.3.2. GNS2DNS When a resolver encounters one or more GNS2DNS records and the remaining name is empty and the desired record type is GNS2DNS, the GNS2DNS records are returned. Otherwise, it is expected that the resolver first resolves the IP addresses of the specified DNS name servers. The DNS name may have to be converted to an IDNA compliant representation [RFC5890] for resolution in DNS. GNS2DNS records MAY contain numeric IPv4 or IPv6 addresses, allowing the resolver to skip this step. The DNS server names may themselves be names in GNS or DNS. If the rightmost label of the DNS server name is the extension label (U+002B, "+"), the rest of the name is to be interpreted relative to the zone of the GNS2DNS record. If the DNS server name ends in a label representation of a zone key, the DNS server name is to be resolved against the GNS zone zk. Multiple GNS2DNS records may be stored under the same label, in which case the resolver MUST try all of them. The resolver MAY try them in any order or even in parallel. If multiple GNS2DNS records are present, the DNS name MUST be identical for all of them, if not the resolution fails and an appropriate error is SHOULD be returned to the application. Schanzenbach, et al. Expires 30 August 2022 [Page 36] Internet-Draft The GNU Name System February 2022 If there are DNSSEC DS records or any other records used to secure the connection with the DNS servers stored under the label, the DNS resolver SHOULD use them to secure the connection with the DNS server. Once the IP addresses of the DNS servers have been determined, the DNS name from the GNS2DNS record is appended to the remainder of the name to be resolved, and resolved by querying the DNS name server(s). The synthesized name may have to be converted to an IDNA compliant representation [RFC5890] for resolution in DNS. If such a conversion is not possible, the resolution MUST be aborted and an error MUST be returned. The information that the critical record could not be processed SHOULD be returned in the error description. The implementation MAY choose not to return the reason for the failure, merely complicating troubleshooting for the user. As the DNS servers specified are possibly authoritative DNS servers, the GNS resolver MUST support recursive DNS resolution and MUST NOT delegate this to the authoritative DNS servers. The first successful recursive name resolution result is returned to the application. In addition, the resolver SHOULD return the queried DNS name as a supplemental LEHO record (see Section 5.3.1) with a relative expiration time of one hour. Once the transition from GNS into DNS is made through a GNS2DNS record, there is no "going back". The (possibly recursive) resolution of the DNS name MUST NOT delegate back into GNS and should only follow the DNS specifications. For example, names contained in DNS CNAME records MUST NOT be interpreted as GNS names. GNS resolvers SHOULD offer a configuration option to disable DNS processing to avoid information leakage and provide a consistent security profile for all name resolutions. Such resolvers would return an empty record set upon encountering a GNS2DNS record during the recursion. However, if GNS2DNS records are encountered in the record set for the apex label and a GNS2DNS record is explicitly requested by the application, such records MUST still be returned, even if DNS support is disabled by the GNS resolver configuration. 7.3.3. BOX When a BOX record is received, a GNS resolver must unbox it if the name to be resolved continues with "_SERVICE._PROTO". Otherwise, the BOX record is to be left untouched. This way, TLSA (and SRV) records do not require a separate network request, and TLSA records become inseparable from the corresponding address records. Schanzenbach, et al. Expires 30 August 2022 [Page 37] Internet-Draft The GNU Name System February 2022 7.3.4. Zone Delegation Records When the resolver encounters a record of a supported zone delegation record type (such as PKEY or EDKEY) and the remainder of the name is not empty, resolution continues recursively with the remainder of the name in the GNS zone specified in the delegation record. Whenever a resolver encounters a new GNS zone, it MUST check against the local revocation list whether the respective zone key has been revoked. If the zone key was revoked, the resolution MUST fail with an empty result set. Implementations MUST NOT allow multiple different zone delegations under a single label. Implementations MAY support any subset of ztypes. Handling of Implementations MUST NOT process zone delegation for the apex label "@". Upon encountering a zone delegation record under this label, resolution fails and an error MUST be returned. The implementation MAY choose not to return the reason for the failure, merely impacting troubleshooting information for the user. If the remainder of the name to resolve is empty and a record set was received containing only a single delegation record, the recursion is continued with the record value as authoritative zone and the apex label "@" as remaining name. Except in the case where the desired record type as specified by the application is equal to the ztype, in which case the delegation record is returned. 7.3.5. NICK NICK records are only relevant to the recursive resolver if the record set in question is the final result which is to be returned to the application. The encountered NICK records may either be supplemental (see Section 5) or non-supplemental. If the NICK record is supplemental, the resolver only returns the record set if one of the non-supplemental records matches the queried record type. It is possible that one record set contains both supplemental and non- supplemental NICK records. The differentiation between a supplemental and non-supplemental NICK record allows the application to match the record to the authoritative zone. Consider the following example: Query: alice.example (type=A) Result: A: 192.0.2.1 NICK: eve (non-Supplemental) Schanzenbach, et al. Expires 30 August 2022 [Page 38] Internet-Draft The GNU Name System February 2022 In this example, the returned NICK record is non-supplemental. For the application, this means that the NICK belongs to the zone "alice.example" and is published under the apex label along with an A record. The NICK record should be interpreted as: The zone defined by "alice.example" wants to be referred to as "eve". In contrast, consider the following: Query: alice.example (type=AAAA) Result: AAAA: 2001:DB8::1 NICK: john (Supplemental) In this case, the NICK record is marked as supplemental. This means that the NICK record belongs to the zone "example" and is published under the label "alice" along with an A record. The NICK record should be interpreted as: The zone defined by "example" wants to be referred to as "john". This distinction is likely useful for other records published as supplemental. 8. Internationalization and Character Encoding All names in GNS are encoded in UTF-8 [RFC3629]. Labels MUST be canonicalized using Normalization Form C (NFC) [Unicode-UAX15]. This does not include any DNS names found in DNS records, such as CNAME record data, which is internationalized through the IDNA specifications [RFC5890]. 9. Security and Privacy Considerations 9.1. Availability In order to ensure availability of records beyond their absolute expiration times, implementations MAY allow to locally define relative expiration time values of records. Records can then be published recurringly with updated absolute expiration times by the implementation. Implementations MAY allow users to manage private records in their zones that are not published in the storage. Private records are considered just like regular records when resolving labels in local zones, but their data is completely unavailable to non-local users. Schanzenbach, et al. Expires 30 August 2022 [Page 39] Internet-Draft The GNU Name System February 2022 9.2. Agility The security of cryptographic systems depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering of the protocol used by the system to ensure that there are no non- cryptographic ways to bypass the security of the overall system. This is why developers of applications managing GNS zones SHOULD select a default ztype considered secure at the time of releasing the software. For applications targeting end users that are not expected to understand cryptography, the application developer MUST NOT leave the ztype selection of new zones to end users. This document concerns itself with the selection of cryptographic algorithms used in GNS. The algorithms identified in this document are not known to be broken (in the cryptographic sense) at the current time, and cryptographic research so far leads us to believe that they are likely to remain secure into the foreseeable future. However, this is not necessarily forever, and it is expected that new revisions of this document will be issued from time to time to reflect the current best practices in this area. In terms of crypto-agility, whenever the need for an updated cryptographic scheme arises to, for example, replace ECDSA over Ed25519 for PKEY records it may simply be introduced through a new record type. Such a new record type may then replace the delegation record type for future records. The old record type remains and zones can iteratively migrate to the updated zone keys. To ensure that implementations correctly generate an error message when encountering a ztype that they do not support, current and future delegation records must always have the CRITICAL flag set. 9.3. Cryptography GNS PKEY zone keys use ECDSA over Ed25519. This is an unconventional choice, as ECDSA is usually used with other curves. However, standardized ECDSA curves are problematic for a range of reasons described in the Curve25519 and EdDSA papers [ed25519]. Using EdDSA directly is also not possible, as a hash function is used on the private key which destroys the linearity that the key blinding in GNS depends upon. We are not aware of anyone suggesting that using Ed25519 instead of another common curve of similar size would lower the security of ECDSA. GNS uses 256-bit curves because that way the encoded (public) keys fit into a single DNS label, which is good for usability. Schanzenbach, et al. Expires 30 August 2022 [Page 40] Internet-Draft The GNU Name System February 2022 In order to ensure ciphertext indistinguishability, care must be taken with respect to the initialization vector in the counter block. In our design, the IV always includes the expiration time of the record block. When applications store records with relative expiration times, monotonicity is implicitly ensured because each time a block is published into the storage, its IV is unique as the expiration time is calculated dynamically and increases monotonically with the system time. Still, an implementation MUST ensure that when relative expiration times are decreased, the expiration time of the next record block MUST be after the last published block. For records where an absolute expiration time is used, the implementation MUST ensure that the expiration time is always increased when the record data changes. For example, the expiration time on the wire may be increased by a single microsecond even if the user did not request a change. In case of deletion of all resource records under a label, the implementation MUST keep track of the last absolute expiration time of the last published resource block. Implementations MAY define and use a special record type as a tombstone that preserves the last absolute expiration time, but then MUST take care to not publish a block with this record. When new records are added under this label later, the implementation MUST ensure that the expiration times are after the last published block. Finally, in order to ensure monotonically increasing expiration times the implementation MUST keep a local record of the last time obtained from the system clock, so as to construct a monotonic clock in case the system clock jumps backwards. 9.4. Abuse Mitigation GNS names are UTF-8 strings. Consequently, GNS faces similar issues with respect to name spoofing as DNS does for internationalized domain names. In DNS, attackers may register similar sounding or looking names (see above) in order to execute phishing attacks. GNS zone administrators must take into account this attack vector and incorporate rules in order to mitigate it. Further, DNS can be used to combat illegal content on the internet by having the respective domains seized by authorities. However, the same mechanisms can also be abused in order to impose state censorship, which is one of the motivations behind GNS. Hence, such a seizure is, by design, difficult to impossible in GNS. Schanzenbach, et al. Expires 30 August 2022 [Page 41] Internet-Draft The GNU Name System February 2022 9.5. Zone Management In GNS, zone administrators need to manage and protect their zone keys. Once a zone key is lost, it cannot be recovered or revoked. Revocation messages may be pre-calculated if revocation is required in case a zone key is lost. Zone administrators, and for GNS this includes end-users, are required to responsibly and diligently protect their cryptographic keys. GNS supports offline signing of records. Similarly, users are required to manage their local start zone configuration. In order to ensure integrity and availability or names, users must ensure that their local start zone information is not compromised or outdated. It can be expected that the processing of zone revocations and an initial start zone is provided with a GNS implementation ("drop shipping"). Shipping an initial start zone configuration effectively establishes a root zone. Extension and customization of the zone is at the full discretion of the user. While implementations following this specification will be interoperable, if two implementations connect to different storages they are mutually unreachable. This may lead to a state where a record may exist in the global namespace for a particular name, but the implementation is not communicating with the storage and is hence unable to resolve it. This situation is similar to a split-horizon DNS configuration. Which storages are implemented usually depends on the application it is built for. The storage used will most likely depend on the specific application context using GNS resolution. For example, one application may be the resolution of hidden services within the Tor network, which may suggest using Tor routers for storage. Implementations of "aggregated" storages are conceivable, but are expected to be the exception. 9.6. Impact of DHTs as Underlying Storage This document does not specify the properties of the underlying storage which is required by any GNS implementation. It is important to note that the properties of the underlying storage are directly inherited by the GNS implementation. This includes both security as well as other non-functional properties such as scalability and performance. Implementers should take great care when selecting or implementing a DHT for use as storage in a GNS implementation. DHTs with reasonable security and performance properties exist [R5N]. It should also be taken into consideration that GNS implementations which build upon different DHT overlays are unlikely to be interoperable with each other. Schanzenbach, et al. Expires 30 August 2022 [Page 42] Internet-Draft The GNU Name System February 2022 9.7. Revocations Zone administrators are advised to pre-generate zone revocations and to securely store the revocation information in case the zone key is lost, compromised or replaced in the future. Pre-calculated revocations may cease to be valid due to expirations or protocol changes such as epoch adjustments. Consequently, implementers and users must take precautions in order to manage revocations accordingly. Revocation payloads do not include a 'new' key for key replacement. Inclusion of such a key would have two major disadvantages: 1. If a revocation is published after a private key was compromised, allowing key replacement would be dangerous: if an adversary took over the private key, the adversary could then broadcast a revocation with a key replacement. For the replacement, the compromised owner would have no chance to issue even a revocation. Thus, allowing a revocation message to replace a private key makes dealing with key compromise situations worse. 2. Sometimes, key revocations are used with the objective of changing cryptosystems. Migration to another cryptosystem by replacing keys via a revocation message would only be secure as long as both cryptosystems are still secure against forgery. Such a planned, non-emergency migration to another cryptosystem should be done by running zones for both cipher systems in parallel for a while. The migration would conclude by revoking the legacy zone key only once it is deemed no longer secure, and hopefully after most users have migrated to the replacement. 9.8. Label Guessing Record blocks are published in encrypted form using keys derived from the zone key and record label. Zone administrators should carefully consider if the label and zone key may be public or if those should be used and considered as a shared secret. Unlike zone keys, labels can also be guessed by an attacker in the network observing queries and responses. Given a known and targeted zone key, the use of well known or easily guessable labels effectively result in general disclosure of the records to the public. If the labels and hence the records should be kept secret except to those knowing a secret label and the zone in which to look, the label must be chosen accordingly. It is recommended to then use a label with sufficient entropy as to prevent guessing attacks. Schanzenbach, et al. Expires 30 August 2022 [Page 43] Internet-Draft The GNU Name System February 2022 It should be noted that this attack on labels only applies if the zone key is somehow disclosed to the adversary. GNS itself does not disclose it during a lookup or when resource records are published as the zone keys are blinded beforehand. However, zone keys do become public during revocation. 10. GANA Considerations GANA [GANA] manages the "GNU Name System Record Types" registry. Each entry has the following format: * Name: The name of the record type (case-insensitive ASCII string, restricted to alphanumeric characters. For zone delegation records, the assigned number represents the ztype value of the zone. * Number: 32-bit, above 65535 * Comment: Optionally, a brief English text describing the purpose of the record type (in UTF-8) * Contact: Optionally, the contact information of a person to contact for further information. * References: Optionally, references describing the record type (such as an RFC) The registration policy for this registry is "First Come First Served". This policy is modeled on that described in [RFC8126], and describes the actions taken by GANA: Adding new records is possible after expert review, using a first- come-first-served policy for unique name allocation. Experts are responsible to ensure that the chosen "Name" is appropriate for the record type. The registry will assign a unique number for the entry. The current contact(s) for expert review are reachable at gns- registry@gnunet.org. Any request MUST contain a unique name and a point of contact. The contact information MAY be added to the registry given the consent of the requester. The request MAY optionally also contain relevant references as well as a descriptive comment as defined above. GANA has assigned numbers for the record types defined in this specification in the "GNU Name System Record Types" registry as listed in Figure 19. Schanzenbach, et al. Expires 30 August 2022 [Page 44] Internet-Draft The GNU Name System February 2022 Number | Name | Contact | References | Comment -------+---------+---------+------------+------------------------- 65536 | PKEY | N/A | [This.I-D] | GNS zone delegation (PKEY) 65537 | NICK | N/A | [This.I-D] | GNS zone nickname 65538 | LEHO | N/A | [This.I-D] | GNS legacy hostname 65540 | GNS2DNS | N/A | [This.I-D] | Delegation to DNS 65541 | BOX | N/A | [This.I-D] | Boxed records 65551 | REDIRECT| N/A | [This.I-D] | Redirection record. 65556 | EDKEY | N/A | [This.I-D] | GNS zone delegation (EDKEY) Figure 19: The GANA Resource Record Registry. GANA has assigned signature purposes in its "GNUnet Signature Purpose" registry as listed in Figure 20. Purpose | Name | References | Comment --------+-----------------+------------+-------------------------- 3 | GNS_REVOCATION | [This.I-D] | GNS zone key revocation 15 | GNS_RECORD_SIGN | [This.I-D] | GNS record set signature Figure 20: Requested Changes in the GANA GNUnet Signature Purpose Registry. 11. IANA Considerations This document makes no requests for IANA action. This section may be removed on publication as an RFC. 12. Implementation and Deployment Status There are two implementations conforming to this specification written in C and Go, respectively. The C implementation as part of GNUnet [GNUnetGNS] represents the original and reference implementation. The Go implementation [GoGNS] demonstrates how two implementations of GNS are interoperable given that they are built on top of the same underlying DHT storage. Currently, the GNUnet peer-to-peer network [GNUnet] is an active deployment of GNS on top of its [R5N] DHT. The [GoGNS] implementation uses this deployment by building on top of the GNUnet DHT services available on any GNUnet peer. It shows how GNS implementations can attach to this existing deployment and participate in name resolution as well as zone publication. The self-sovereign identity system re:claimID [reclaim] is using GNS in order to selectively share identity attributes and attestations with third parties. Schanzenbach, et al. Expires 30 August 2022 [Page 45] Internet-Draft The GNU Name System February 2022 The Ascension tool [Ascension] facilitates the migration of DNS zones to GNS zones by translating information retrieved from a DNS zone transfer into a GNS zone. 13. Acknowledgements The authors thank D. J. Bernstein, A. Farrel and S. Bortzmeyer for their insightful reviews. We thank NLnet and NGI DISCOVERY for funding work on the GNU Name System. 14. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, . [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model", RFC 3826, DOI 10.17487/RFC3826, June 2004, . Schanzenbach, et al. Expires 30 August 2022 [Page 46] Internet-Draft The GNU Name System February 2022 [RFC5237] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for the Protocol Field", BCP 37, RFC 5237, DOI 10.17487/RFC5237, February 2008, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008", RFC 5895, DOI 10.17487/RFC5895, September 2010, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, . [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013, . [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Schanzenbach, et al. Expires 30 August 2022 [Page 47] Internet-Draft The GNU Name System February 2022 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . [RFC9106] Biryukov, A., Dinu, D., Khovratovich, D., and S. Josefsson, "Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications", RFC 9106, DOI 10.17487/RFC9106, September 2021, . [GANA] GNUnet e.V., "GNUnet Assigned Numbers Authority (GANA)", April 2020, . [MODES] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques", December 2001, . [CrockfordB32] Douglas, D., "Base32", March 2019, . [XSalsa20] Bernstein, D., "Extending the Salsa20 nonce", 2011, . [Unicode-UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms, Revision 31", September 2009, . [Unicode-UTS46] The Unicode Consortium, "Unicode Technical Standard #46: Unicode IDNA Compatibility Processing, Revision 27", August 2021, . 15. Informative References [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . Schanzenbach, et al. Expires 30 August 2022 [Page 48] Internet-Draft The GNU Name System February 2022 [RFC7363] Maenpaa, J. and G. Camarillo, "Self-Tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD)", RFC 7363, DOI 10.17487/RFC7363, September 2014, . [RFC8324] Klensin, J., "DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?", RFC 8324, DOI 10.17487/RFC8324, February 2018, . [Tor224] Goulet, D., Kadianakis, G., and N. Mathewson, "Next- Generation Hidden Services in Tor", November 2013, . [SDSI] Rivest, R. and B. Lampson, "SDSI - A Simple Distributed Security Infrastructure", April 1996, . [Kademlia] Maymounkov, P. and D. Mazieres, "Kademlia: A peer-to-peer information system based on the xor metric.", 2002, . [ed25519] Bernstein, D., Duif, N., Lange, T., Schwabe, P., and B. Yang, "High-Speed High-Security Signatures", 2011, . [GNS] Wachs, M., Schanzenbach, M., and C. Grothoff, "A Censorship-Resistant, Privacy-Enhancing and Fully Decentralized Name System", 2014, . [R5N] Evans, N. S. and C. Grothoff, "R5N: Randomized recursive routing for restricted-route networks", 2011, . [SecureNS] Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum, "Towards secure name resolution on the Internet", 2018, . [GNUnetGNS] GNUnet e.V., "The GNUnet GNS Implementation", . [Ascension] GNUnet e.V., "The Ascension Implementation", . Schanzenbach, et al. Expires 30 August 2022 [Page 49] Internet-Draft The GNU Name System February 2022 [GNUnet] GNUnet e.V., "The GNUnet Project", . [reclaim] GNUnet e.V., "The GNUnet Project", . [GoGNS] Fix, B., "The Go GNS Implementation", . Appendix A. Base32GNS This table defines the encode symbol and decode symbol for a given symbol value. It can be used to implement the encoding by reading it as: A character "A" or "a" is decoded to a 5 bit value 10 when decoding. A 5 bit block with a value of 18 is encoded to the character "J" when encoding. If the bit length of the byte string to encode is not a multiple of 5 it is padded to the next multiple with zeroes. In order to further increase tolerance for failures in character recognition, the letter "U" MUST be decoded to the same value as the letter "V" in Base32GNS. Schanzenbach, et al. Expires 30 August 2022 [Page 50] Internet-Draft The GNU Name System February 2022 Symbol Decode Encode Value Symbol Symbol 0 0 O o 0 1 1 I i L l 1 2 2 2 3 3 3 4 4 4 5 5 5 6 6 6 7 7 7 8 8 8 9 9 9 10 A a A 11 B b B 12 C c C 13 D d D 14 E e E 15 F f F 16 G g G 17 H h H 18 J j J 19 K k K 20 M m M 21 N n N 22 P p P 23 Q q Q 24 R r R 25 S s S 26 T t T 27 V v U u V 28 W w W 29 X x X 30 Y y Y 31 Z z Z Figure 21: The Base32GNS Alphabet Including the Additional U Encode Symbol. Appendix B. Test Vectors The following are test vectors for the Base32GNS encoding used for zTLDs. The strings are encoded without the zero terminator. Schanzenbach, et al. Expires 30 August 2022 [Page 51] Internet-Draft The GNU Name System February 2022 Base32GNS-Encode: Input string: "Hello World" Output string: "91JPRV3F41BPYWKCCG" Input bytes: 474e55204e616d652053797374656d Output string: "8X75A82EC5PPA82KF5SQ8SBD" Base32GNS-Decode: Input string: "91JPRV3F41BPYWKCCG" Output string: "Hello World" Input string: "91JPRU3F41BPYWKCCG" Output string: "Hello World" The following represents test vectors for record sets with a variety of record types and flags for both PKEY and EDKEY zones. Zone private key (d, big-endian): 50d7b652a4efeadf f37396909785e595 2171a02178c8e7d4 50fa907925fafd98 Zone identifier (ztype|zkey): 00010000677c477d 2d93097c85b195c6 f96d84ff61f5982c 2c4fe02d5a11fedf b0c2901f Encoded zone identifier (zTLD): 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W Label: testdelegation RRCOUNT: 1 Record #0 EXPIRATION: 2463385894000000 DATA_SIZE: 36 TYPE: 65536 FLAGS: 0001 DATA: 0001000021e3b30f f93bc6d35ac8c6e0 e13afdff794cb7b4 Schanzenbach, et al. Expires 30 August 2022 [Page 52] Internet-Draft The GNU Name System February 2022 4bbbc748d259d0a0 284dbe84 RDATA: 0008c06fb9281580 0024000100010000 0001000021e3b30f f93bc6d35ac8c6e0 e13afdff794cb7b4 4bbbc748d259d0a0 284dbe84 Encryption NONCE|EXPIRATION|BLOCK COUNTER: e90a00610008c06f b928158000000001 Encryption key (K): 864e7138eae7fd91 a30136899c132b23 acebdb2cef43cb19 f6bf55b67db9b3b3 Storage key (q): 4adc67c5ecee9f76 986abd71c2224a3d ce2e917026c9a09d fd44cef3d20f55a2 7332725a6c8afbbb b0f7ec9af1cc4264 1299406b04fd9b5b 5791f86c4b08d5f4 BDATA: 41dc7b5f2176ba59 199cafb9e3c82579 71b21ccb6de51d38 bd2a21e9322c6af8 4243e8de876b5b76 37462e79b2c162db 4014d5c9 RRBLOCK: 000000a400010000 182bb636eda79f79 5711bc2708adbb24 2a60446ad3c30803 121d03d348b7ceb6 01a968a5eac3cb95 Schanzenbach, et al. Expires 30 August 2022 [Page 53] Internet-Draft The GNU Name System February 2022 ed58c1c5386f4ab6 539edd8099b4893a be83f242115e3e35 03965dc924a6001a e94ecab9b2f25c4c 6fdc7ffbe9f3b2a2 854b321b1d7ea9ab 0008c06fb9281580 41dc7b5f2176ba59 199cafb9e3c82579 71b21ccb6de51d38 bd2a21e9322c6af8 4243e8de876b5b76 37462e79b2c162db 4014d5c9 Zone private key (d, big-endian): 50d7b652a4efeadf f37396909785e595 2171a02178c8e7d4 50fa907925fafd98 Zone identifier (ztype|zkey): 00010000677c477d 2d93097c85b195c6 f96d84ff61f5982c 2c4fe02d5a11fedf b0c2901f Encoded zone identifier (zTLD): 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W Label: namesystem RRCOUNT: 3 Record #0 EXPIRATION: 2463385894000000 DATA_SIZE: 16 TYPE: 28 FLAGS: 0000 DATA: 0000000000000000 00000000deadbeef Record #1 EXPIRATION: 49556645701000000 DATA_SIZE: 6 Schanzenbach, et al. Expires 30 August 2022 [Page 54] Internet-Draft The GNU Name System February 2022 TYPE: 65537 FLAGS: 8000 DATA: e6849be7a7b0 Record #2 EXPIRATION: 6131101992 DATA_SIZE: 11 TYPE: 16 FLAGS: 4004 DATA: 48656c6c6f20576f 726c64 RDATA: 0008c06fb9281580 001000000000001c 0000000000000000 00000000deadbeef 00b00f81b7449b40 0006800000010001 e6849be7a7b00000 00016d713128000b 4004000000104865 6c6c6f20576f726c 6400000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Encryption NONCE|EXPIRATION|BLOCK COUNTER: a5df4a330005d82a 1a7efea100000001 Encryption key (K): 39a8824c4da40242 d9e05eb46cdf280f 29a116f8acfd94c8 6df48b2b7aac82ff Storage key (q): 07f6e965f75c815d 35fea2212692c8fc f9b575cb42f0fd84 Schanzenbach, et al. Expires 30 August 2022 [Page 55] Internet-Draft The GNU Name System February 2022 5d4d7327199cf3dd dcbc5565ca2b81fe b08088ae2bb2afd0 d85f2fed85e170be ee86bf67ce2b9ece BDATA: 158cb30b44e088bc 7def82f8a0428512 de3bebd23772c7f0 51269662f4046d14 6f40ae5bf3713121 9684e314962e23ba 5dae79056d9e66ac a296736986aa8f91 7e2ab5055ed6cc2b 44835bb00c4a57d9 f400d864cb1587ac 5078d9e4b98021fb 2719c8a3ca268fc2 94efe588bd622423 eb3b8e67af1a5185 a1fcb58e99b730cc RRBLOCK: 000000f000010000 ddef91ac40ad25e3 6b65242789ee9662 e195ced12e76245e 10ebc70bbe089906 0277c5c92f3d5a09 f90dd4cb2accfa46 d2a5ff7f841f8207 ade978da078ff49e 04767e0cad4c7bb3 4a478ccc6288b426 e7e3cd1915d39884 3477e98e03af547b 0005d82a1a7efea1 158cb30b44e088bc 7def82f8a0428512 de3bebd23772c7f0 51269662f4046d14 6f40ae5bf3713121 9684e314962e23ba 5dae79056d9e66ac a296736986aa8f91 7e2ab5055ed6cc2b Schanzenbach, et al. Expires 30 August 2022 [Page 56] Internet-Draft The GNU Name System February 2022 44835bb00c4a57d9 f400d864cb1587ac 5078d9e4b98021fb 2719c8a3ca268fc2 94efe588bd622423 eb3b8e67af1a5185 a1fcb58e99b730cc Zone private key (d): 5af7020ee1916032 8832352bbc6a68a8 d71a7cbe1b929969 a7c66d415a0d8f65 Zone identifier (ztype|zkey): 000100143cf4b924 032022f0dc505814 53b85d93b047b63d 446c5845cb48445d db96688f Encoded zone identifier (zTLD): 000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW Label: testdelegation RRCOUNT: 1 Record #0 EXPIRATION: 2463385894000000 DATA_SIZE: 36 TYPE: 65536 FLAGS: 0001 DATA: 0001000021e3b30f f93bc6d35ac8c6e0 e13afdff794cb7b4 4bbbc748d259d0a0 284dbe84 RDATA: 0008c06fb9281580 0024000100010000 0001000021e3b30f f93bc6d35ac8c6e0 e13afdff794cb7b4 4bbbc748d259d0a0 284dbe84 Schanzenbach, et al. Expires 30 August 2022 [Page 57] Internet-Draft The GNU Name System February 2022 Encryption NONCE|EXPIRATION: 98132ea86859d35c 88bfd317fa991bcb 0008c06fb9281580 Encryption key (K): 85c429a9567aa633 411a9691e9094c45 281672be586034aa e4a2a2cc716159e2 Storage key (q): abaabac0e1249459 75988395aac0241e 5559c41c4074e255 7b9fe6d154b614fb cdd47fc7f51d786d c2e0b1ece76037c0 a1578c384ec61d44 5636a94e880329e9 BDATA: 7d9ecea3c19ef07b 0db1fab44c5e4477 6ea8d8894e904a0c 35ed1c5c2ff2ed93 bd204b3fcae98192 fad94afbc5bba3a6 de538c01c7e1f65e 2a883cc068c02109 7afd7330 RRBLOCK: 000000b400010014 9bf233198c6d53bb dbac495cabd91049 a684af3f4051baca b0dcf21c8cf27a1a 69ac3485946796d1 e31837f569d71e06 e79c4777ab9c41fa 29cdd198464aac3d aaeea2c192eb6e71 1d0dc7bb76994eca ab837e402ba2c994 4df155b6e96fdf0a 0008c06fb9281580 7d9ecea3c19ef07b Schanzenbach, et al. Expires 30 August 2022 [Page 58] Internet-Draft The GNU Name System February 2022 0db1fab44c5e4477 6ea8d8894e904a0c 35ed1c5c2ff2ed93 bd204b3fcae98192 fad94afbc5bba3a6 de538c01c7e1f65e 2a883cc068c02109 7afd7330 Zone private key (d): 5af7020ee1916032 8832352bbc6a68a8 d71a7cbe1b929969 a7c66d415a0d8f65 Zone identifier (ztype|zkey): 000100143cf4b924 032022f0dc505814 53b85d93b047b63d 446c5845cb48445d db96688f Encoded zone identifier (zTLD): 000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW Label: namesystem RRCOUNT: 3 Record #0 EXPIRATION: 2463385894000000 DATA_SIZE: 16 TYPE: 28 FLAGS: 0000 DATA: 0000000000000000 00000000deadbeef Record #1 EXPIRATION: 49556645701000000 DATA_SIZE: 6 TYPE: 65537 FLAGS: 8000 DATA: e6849be7a7b0 Record #2 Schanzenbach, et al. Expires 30 August 2022 [Page 59] Internet-Draft The GNU Name System February 2022 EXPIRATION: 6131101992 DATA_SIZE: 11 TYPE: 16 FLAGS: 4004 DATA: 48656c6c6f20576f 726c64 RDATA: 0008c06fb9281580 001000000000001c 0000000000000000 00000000deadbeef 00b00f81b7449b40 0006800000010001 e6849be7a7b00000 00016d713128000b 4004000000104865 6c6c6f20576f726c 6400000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Encryption NONCE|EXPIRATION: d9402801e26324b6 0c227f25203e9f26 0005d82a1a7f108e Encryption key (K): 20007fe09b16dc86 e0fd0d74fb3d5d0b 7962d7fe5301a7b4 ec9f8bfd935cc9d2 Storage key (q): 82584d4d2c314be7 5b304222a63fa6e4 e52ea63d7dbd153c 6e3ba1ae749c5772 e1c6b245633c5563 37c7fc60b0115888 ad5ade579522e9d7 10fa23cd93e56e8c Schanzenbach, et al. Expires 30 August 2022 [Page 60] Internet-Draft The GNU Name System February 2022 BDATA: ac94e07ec841f0c3 dbcc7098adb72a7e b988687a5cd16d11 823fc15934c1817b df9f38486ac8de17 385b188bd363301d cb93965a962c1226 8c6204f79ef20549 a5c513fba83ef61e 3d7b3255487bff16 be0697934e5c6b9d ddad4c06c15e3743 9a987407eb13db33 4d734abc1cdd163b fe9ed0565294aaf1 f3ae753f4f85ed81 bd5743477eb5a791 06eec69b63ba6dc1 RRBLOCK: 0000010000010014 1e7f6acfa589c933 6eae0bd307c893c4 85a873cf0cbbfd9d 54d04c13e3b7d284 c81e8ec28b873200 87890c9c5684d448 118f4cdda8963e74 d428647c81a65c0c f6a1714fc93cd5c4 97aec1c72926ccd5 cc2b32d5096a968b 34a2eb997c608e0b 0005d82a1a7f108e ac94e07ec841f0c3 dbcc7098adb72a7e b988687a5cd16d11 823fc15934c1817b df9f38486ac8de17 385b188bd363301d cb93965a962c1226 8c6204f79ef20549 a5c513fba83ef61e 3d7b3255487bff16 be0697934e5c6b9d ddad4c06c15e3743 9a987407eb13db33 Schanzenbach, et al. Expires 30 August 2022 [Page 61] Internet-Draft The GNU Name System February 2022 4d734abc1cdd163b fe9ed0565294aaf1 f3ae753f4f85ed81 bd5743477eb5a791 06eec69b63ba6dc1 The following is an example revocation for a zone: Zone private key (d, big-endian scalar): 6fea32c05af58bfa 979553d188605fd5 7d8bf9cc263b78d5 f7478c07b998ed70 Zone identifier (ztype|zkey): 000100002ca223e8 79ecc4bbdeb5da17 319281d63b2e3b69 55f1c3775c804a98 d5f8ddaa Encoded zone identifier (zTLD): 000G001CM8HYGYFCRJXXXDET2WRS50EP7CQ3PTANY71QEQ409ACDBY6XN8 Difficulty (5 base difficulty + 2 epochs): 7 Signed message: 0000003400000003 0005d66da3598127 000100002ca223e8 79ecc4bbdeb5da17 319281d63b2e3b69 55f1c3775c804a98 d5f8ddaa Proof: 0005d66da3598127 0000395d1827c000 3ab877d07570f2b8 3ab877d07570f332 3ab877d07570f4f5 3ab877d07570f50f 3ab877d07570f537 3ab877d07570f599 3ab877d07570f5cd 3ab877d07570f5d9 Schanzenbach, et al. Expires 30 August 2022 [Page 62] Internet-Draft The GNU Name System February 2022 3ab877d07570f66a 3ab877d07570f69b 3ab877d07570f72f 3ab877d07570f7c3 3ab877d07570f843 3ab877d07570f8d8 3ab877d07570f91b 3ab877d07570f93a 3ab877d07570f944 3ab877d07570f98a 3ab877d07570f9a7 3ab877d07570f9b0 3ab877d07570f9df 3ab877d07570fa05 3ab877d07570fa3e 3ab877d07570fa63 3ab877d07570fa84 3ab877d07570fa8f 3ab877d07570fa91 3ab877d07570fad6 3ab877d07570fb0a 3ab877d07570fc0f 3ab877d07570fc43 3ab877d07570fca5 000100002ca223e8 79ecc4bbdeb5da17 319281d63b2e3b69 55f1c3775c804a98 d5f8ddaa053b0259 700039187d1da461 3531502bc4a4eecc c69900d24f8aac54 30f28fc509270133 1f178e290fe06e82 ce2498ce7b23a340 58e3d6a2f247e92b c9d7b9ab Authors' Addresses Martin Schanzenbach GNUnet e.V. Boltzmannstrasse 3 85748 Garching Germany Email: schanzen@gnunet.org Schanzenbach, et al. Expires 30 August 2022 [Page 63] Internet-Draft The GNU Name System February 2022 Christian Grothoff Berner Fachhochschule Hoeheweg 80 CH-2501 Biel/Bienne Switzerland Email: grothoff@gnunet.org Bernd Fix GNUnet e.V. Boltzmannstrasse 3 85748 Garching Germany Email: fix@gnunet.org Schanzenbach, et al. Expires 30 August 2022 [Page 64]