< draft-schanzen-gns-13.txt		draft-schanzen-gns-14.txt >
	Independent Stream M. Schanzenbach		Independent Stream M. Schanzenbach
	Internet-Draft Fraunhofer AISEC		Internet-Draft Fraunhofer AISEC
	Intended status: Informational C. Grothoff		Intended status: Informational C. Grothoff
	Expires: 20 October 2022 Berner Fachhochschule		Expires: 6 November 2022 Berner Fachhochschule
	B. Fix		B. Fix
	GNUnet e.V.		GNUnet e.V.
	18 April 2022		5 May 2022
	The GNU Name System		The GNU Name System
	draft-schanzen-gns-13		draft-schanzen-gns-14
	Abstract		Abstract
	This document contains the GNU Name System (GNS) technical		This document contains the GNU Name System (GNS) technical
	specification. GNS is a decentralized and censorship-resistant name		specification. GNS is a decentralized and censorship-resistant name
	system that provides a privacy-enhancing alternative to the Domain		system that provides a privacy-enhancing alternative to the Domain
	Name System (DNS).		Name System (DNS).
	This document defines the normative wire format of resource records,		This document defines the normative wire format of resource records,
	resolution processes, cryptographic routines and security		resolution processes, cryptographic routines and security
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 20 October 2022.		This Internet-Draft will expire on 6 November 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 28 ¶		skipping to change at page 2, line 28 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4		1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		4. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.1. Zone Top-Level Domain . . . . . . . . . . . . . . . . . . 11		4.1. Zone Top-Level Domain . . . . . . . . . . . . . . . . . . 11
	4.2. Zone Revocation . . . . . . . . . . . . . . . . . . . . . 12		4.2. Zone Revocation . . . . . . . . . . . . . . . . . . . . . 12
	5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 17		5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 16
	5.1. Zone Delegation Records . . . . . . . . . . . . . . . . . 18		5.1. Zone Delegation Records . . . . . . . . . . . . . . . . . 18
	5.1.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . 19		5.1.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . 18
	5.1.2. EDKEY . . . . . . . . . . . . . . . . . . . . . . . . 22		5.1.2. EDKEY . . . . . . . . . . . . . . . . . . . . . . . . 21
	5.2. Redirection Records . . . . . . . . . . . . . . . . . . . 26		5.2. Redirection Records . . . . . . . . . . . . . . . . . . . 26
	5.2.1. REDIRECT . . . . . . . . . . . . . . . . . . . . . . 26		5.2.1. REDIRECT . . . . . . . . . . . . . . . . . . . . . . 26
	5.2.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 26		5.2.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 26
	5.3. Auxiliary Records . . . . . . . . . . . . . . . . . . . . 27		5.3. Auxiliary Records . . . . . . . . . . . . . . . . . . . . 27
	5.3.1. LEHO . . . . . . . . . . . . . . . . . . . . . . . . 28		5.3.1. LEHO . . . . . . . . . . . . . . . . . . . . . . . . 28
	5.3.2. NICK . . . . . . . . . . . . . . . . . . . . . . . . 28		5.3.2. NICK . . . . . . . . . . . . . . . . . . . . . . . . 28
	5.3.3. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 29		5.3.3. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 29
	6. Record Storage . . . . . . . . . . . . . . . . . . . . . . . 30		6. Record Encoding . . . . . . . . . . . . . . . . . . . . . . . 30
	6.1. The Storage Key . . . . . . . . . . . . . . . . . . . . . 31		6.1. The Storage Key . . . . . . . . . . . . . . . . . . . . . 31
	6.2. The Records Block . . . . . . . . . . . . . . . . . . . . 32		6.2. The Records Block . . . . . . . . . . . . . . . . . . . . 32
	7. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 35		7. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 35
	7.1. Start Zones . . . . . . . . . . . . . . . . . . . . . . . 36		7.1. Start Zones . . . . . . . . . . . . . . . . . . . . . . . 36
	7.2. Recursion . . . . . . . . . . . . . . . . . . . . . . . . 37		7.2. Recursion . . . . . . . . . . . . . . . . . . . . . . . . 37
	7.3. Record Processing . . . . . . . . . . . . . . . . . . . . 37		7.3. Record Processing . . . . . . . . . . . . . . . . . . . . 37
	7.3.1. REDIRECT . . . . . . . . . . . . . . . . . . . . . . 38		7.3.1. REDIRECT . . . . . . . . . . . . . . . . . . . . . . 38
	7.3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 39		7.3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 39
	7.3.3. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 40		7.3.3. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 40
	7.3.4. Zone Delegation Records . . . . . . . . . . . . . . . 40		7.3.4. Zone Delegation Records . . . . . . . . . . . . . . . 40
	skipping to change at page 3, line 18 ¶		skipping to change at page 3, line 18 ¶
	9.5. Zone Management . . . . . . . . . . . . . . . . . . . . . 44		9.5. Zone Management . . . . . . . . . . . . . . . . . . . . . 44
	9.6. DHTs as Storage . . . . . . . . . . . . . . . . . . . . . 45		9.6. DHTs as Storage . . . . . . . . . . . . . . . . . . . . . 45
	9.7. Revocations . . . . . . . . . . . . . . . . . . . . . . . 45		9.7. Revocations . . . . . . . . . . . . . . . . . . . . . . . 45
	9.8. Zone Privacy . . . . . . . . . . . . . . . . . . . . . . 46		9.8. Zone Privacy . . . . . . . . . . . . . . . . . . . . . . 46
	9.9. Namespace Ambiguity . . . . . . . . . . . . . . . . . . . 46		9.9. Namespace Ambiguity . . . . . . . . . . . . . . . . . . . 46
	10. GANA Considerations . . . . . . . . . . . . . . . . . . . . . 47		10. GANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
	12. Implementation and Deployment Status . . . . . . . . . . . . 48		12. Implementation and Deployment Status . . . . . . . . . . . . 48
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49
	14. Normative References . . . . . . . . . . . . . . . . . . . . 49		14. Normative References . . . . . . . . . . . . . . . . . . . . 49
	15. Informative References . . . . . . . . . . . . . . . . . . . 51		15. Informative References . . . . . . . . . . . . . . . . . . . 52
	Appendix A. Base32GNS . . . . . . . . . . . . . . . . . . . . . 53		Appendix A. Base32GNS . . . . . . . . . . . . . . . . . . . . . 53
	Appendix B. Example flows . . . . . . . . . . . . . . . . . . . 54		Appendix B. Example flows . . . . . . . . . . . . . . . . . . . 54
	B.1. AAAA Example Resolution . . . . . . . . . . . . . . . . . 54		B.1. AAAA Example Resolution . . . . . . . . . . . . . . . . . 54
	B.2. REDIRECT Example Resolution . . . . . . . . . . . . . . . 55		B.2. REDIRECT Example Resolution . . . . . . . . . . . . . . . 55
	B.3. GNS2DNS Example Resolution . . . . . . . . . . . . . . . 57		B.3. GNS2DNS Example Resolution . . . . . . . . . . . . . . . 57
	Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 58		Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 58
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 71		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 71
	1. Introduction		1. Introduction
	skipping to change at page 4, line 47 ¶		skipping to change at page 4, line 47 ¶
	1.1. Requirements Notation		1.1. Requirements Notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Terminology		2. Terminology
	Application An application refers to a component which uses a GNS		Apex Label This type of label is used to publish resource records in
	implementation to resolve names into records and processes its		a zone that can be resolved without providing a specific label.
	contents.		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).
	Resolver The resolver is the part of the GNS implementation which		Application A component which uses a GNS implementation to resolve
	provides the recursive name resolution logic defined in Section 7.		names into records and processes its contents.
	Zone Master The zone master is the part of the GNS implementation		Blinded Zone Key The key derived from a zone key and a label. The
	which provides local zone management and publication as defined in		zone key and the blinded zone key are unlinkable without knowledge
	Section 6.		of the label.
			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
			(see Section 5.3.3), every separator label in a name delegates to
			another zone.
			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 might be easily
			confused with other labels through registration policies (see also
			Section 9.4).
	Name A name in GNS is a domain name as defined in [RFC8499] as an		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		ordered list of labels. Names are UTF-8 [RFC3629] strings
	consisting of the list of labels concatenated with a label		consisting of the list of labels concatenated with a label
	separator. Names are resolved starting from the rightmost label.		separator. Names are resolved starting from the rightmost label.
	GNS does not impose length restrictions on names or labels.		GNS does not impose length restrictions on names or labels.
	However, applications MAY ensure that name and label lengths are		However, applications MAY ensure that name and label lengths are
	compatible with DNS and in particular IDNA [RFC5890]. In the		compatible with DNS and in particular IDNA [RFC5890]. In the
	spirit of [RFC5895], applications MAY preprocess names and labels		spirit of [RFC5895], applications MAY preprocess names and labels
	to ensure compatibility with DNS or support specific user		to ensure compatibility with DNS or support specific user
	expectations, for example according to [Unicode-UTS46].		expectations, for example according to [Unicode-UTS46].
	Label A GNS label is a label as defined in [RFC8499]. Labels are		Resolver The component of a GNS implementation which provides the
	UTF-8 strings in Unicode Normalization Form C (NFC)		recursive name resolution logic defined in Section 7.
	[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 might be easily
	confused with other labels through registration policies (see also
	Section 9.4).
	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		Resource Record A GNS resource record is the information associated
	redirections where the redirection target is defined relative to		with a label in a GNS zone. A GNS resource record contains
	the authoritative zone of the redirection record (Section 5.2).		information as defined by its resource record type.
	The extension label is represented using the character U+002B ("+"
	without the quotes).
	Label Separator Labels in a name are separated using the label		Start Zone In order to resolve any given GNS name an initial start
	separator U+002E ("." without the quotes). In GNS, with the		zone must be determined for this name. The start zone can be
	exceptions of zone Top-Level Domains (see below) and boxed records		explicitly defined through a zTLD. Otherwise, it is determined
	(see Section 5.3.3), every separator label in a name delegates to		through a local suffix-to-zone mapping (see Section 7.1).
	another zone.
	Top-Level Domain The rightmost part of a GNS name is a GNS Top-Level		Top-Level Domain The rightmost part of a GNS name is a GNS Top-Level
	Domain (TLD). A GNS TLD can consist of one or more labels.		Domain (TLD). A GNS TLD can consist of one or more labels.
	Unlike DNS Top-Level Domains (defined in [RFC8499]), GNS does not		Unlike DNS Top-Level Domains (defined in [RFC8499]), GNS does not
	expect all users to use the same global root zone. Instead, with		expect all users to use the same global root zone. Instead, with
	the exception of Zone Top-Level Domains (see below), GNS TLDs are		the exception of Zone Top-Level Domains (see below), GNS TLDs are
	typically part of the configuration of the local resolver (see		typically part of the configuration of the local resolver (see
	Section 7.1), and might thus not be globally unique.		Section 7.1), and might thus not be globally unique.
	Zone A GNS zone contains authoritative information (resource		Zone A GNS zone contains authoritative information (resource
	records). A zone is uniquely identified by its zone key. Unlike		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		DNS zones, a GNS zone does not need to have a SOA record under the
	apex label.		apex label.
	Zone Type The type of a GNS zone determines the cipher system and		Zone Key A key which uniquely identifies a zone. It is usually a
	binary encoding format of the zone key, blinded zone keys, and		public key of an asymmetric key pair.
	signatures.
	Zone Key The zone key uniquely identifies a zone. The zone key is
	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)		Zone Key Derivation Function The zone key derivation function (ZKDF)
	blinds a zone key using a label.		blinds a zone key using a label.
	Zone Owner The owner of a GNS zone is the holder of the secret		Zone Master The component of a GNS implementation which provides
	(typically a private key) that (together with a label and a value		local zone management and publication as defined in Section 6.
	to sign) allows the creation of zone signatures that can be
	validated against the respective blinded zone key.		Zone Owner 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		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		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		zone type and zone key of a zone. Due to the statistical
	uniqueness of zone keys, zTLDs are also globally unique. A zTLD		uniqueness of zone keys, zTLDs are also globally unique. A zTLD
	label sequence can only be distinguished from ordinary TLD label		label sequence can only be distinguished from ordinary TLD label
	sequences by attempting to decode the labels into a zone type and		sequences by attempting to decode the labels into a zone type and
	zone key.		zone key.
	Start Zone In order to resolve any given GNS name an initial start		Zone Type The type of a GNS zone determines the cipher system and
	zone must be determined for this name. The start zone can be		binary encoding format of the zone key, blinded zone keys, and
	explicitly defined through a zTLD. Otherwise, it is determined		signatures.
	through a local suffix-to-zone mapping (see Section 7.1).
	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		3. Overview
	In GNS, any user can create and manage one or more cryptographically		In GNS, any user can create and manage one or more zones (Section 4)
	secured zones (Section 4) as part of a zone master implementation.		as part of a zone master implementation. Zones are uniquely
	Zones are uniquely identified by a zone key. Zone contents are		identified by a zone key. Zone contents are signed using blinded
	signed using blinded private keys and encrypted using derived secret		private keys and encrypted using derived secret keys. The zone type
	keys. The zone type determines the respective set of cryptographic		determines the respective set of cryptographic operations and the
	operations and the wire formats for encrypted data, public keys and		wire formats for encrypted data, public keys and signatures.
	signatures.
	A zone can be populated with mappings from labels to resource records		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		by its owner (Section 5). A label can be mapped to a delegation
	record which results in the corresponding subdomain being delegated		record which results in the corresponding subdomain being delegated
	to another zone. Circular delegations are explicitly allowed,		to another zone. Circular delegations are explicitly allowed,
	including delegating a subdomain to its immediate parent zone. In		including delegating a subdomain to its immediate parent zone. In
	order to support (legacy) applications as well as to facilitate the		order to support (legacy) applications as well as to facilitate the
	use of petnames, GNS defines auxiliary record types in addition to		use of petnames, GNS defines auxiliary record types in addition to
	supporting existing DNS records.		supporting existing DNS records.
	Zone contents are encrypted and signed before being published in a		Zone contents are encrypted and signed before being published in a
	distributed key-value storage (Section 6) as illustrated in Figure 1.		key-value storage (Section 6) as illustrated in Figure 1. In this
	In this process, unique zone identification is hidden from the		process, unique zone identification is hidden from the network
	network through the use of key blinding. Key blinding allows the		through the use of key blinding. Key blinding allows the creation of
	creation of signatures for zone contents using a blinded public/		signatures for zone contents using a blinded public/private key pair.
	private key pair. This blinding is realized using a deterministic		This blinding is realized using a deterministic key derivation from
	key derivation from the original zone key and corresponding private		the original zone key and corresponding private key using record
	key using record label values as blinding factors. Specifically, the		label values as blinding factors. Specifically, the zone owner can
	zone owner can derive blinded private keys for each record set		derive blinded private keys for each record set published under a
	published under a label, and a resolver can derive the corresponding		label, and a resolver can derive the corresponding blinded public
	blinded public keys. It is expected that GNS implementations use		keys. It is expected that GNS implementations use distributed or
	distributed or decentralized storages such as distributed hash tables		decentralized storages such as distributed hash tables (DHT) in order
	(DHT) in order to facilitate availability within a network without		to facilitate availability within a network without the need for
	the need for dedicated infrastructure. Specification of such a		dedicated infrastructure. Specification of such a distributed or
	distributed or decentralized storage is out of scope of this		decentralized storage is out of scope of this document, but possible
	document, but possible existing implementations include those based		existing implementations include those based on [RFC7363], [Kademlia]
	on [RFC7363], [Kademlia] or [R5N].		or [R5N].
	Local Host | Remote | Remote Host		Local Host | Remote | Remote Host
	| Storage |		| Storage |
	| |		| |
	| +---------+ |		| +---------+ |
	| / /| |		| / /| |
	Publish | +---------+ | | Publish		Publish | +---------+ | | Publish
	+---------+ Records | | | | | Records +---------+		+---------+ Records | | | | | Records +---------+
	| Zone |----------|->| Record | |<-|----------| Zone |		| Zone |----------|->| Record | |<-|----------| Zone |
	| Master | | | Storage | | | | Master |		| Master | | | Storage | | | | Master |
	skipping to change at page 9, line 36 ¶		skipping to change at page 9, line 36 ¶
	Figure 2: High-level view of the GNS resolution process.		Figure 2: High-level view of the GNS resolution process.
	In the remainder of this document, the "implementer" refers to the		In the remainder of this document, the "implementer" refers to the
	developer building a GNS implementation including the resolver, zone		developer building a GNS implementation including the resolver, zone
	master, and supporting configuration such as start zones		master, and supporting configuration such as start zones
	(Section 7.1).		(Section 7.1).
	4. Zones		4. Zones
	A zone master implementation SHOULD enable the user to create and		A zone master implementation SHOULD enable the zone owners to create
	manage zones. If this functionality is not implemented, names can		and manage zones. If this functionality is not implemented, names
	still be resolved if zone keys for the initial step in the name		can still be resolved if zone keys for the initial step in the name
	resolution are available (see Section 7).		resolution are available (see Section 7).
	A zone in GNS is uniquely identified by its zone type and zone key.		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)		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		string. A zone type (ztype) is a unique 32-bit number. This number
	corresponds to a resource record type number identifying a delegation		corresponds to a resource record type number identifying a delegation
	record type in the GNUnet Assigned Numbers Authority [GANA]. The		record type in the GNUnet Assigned Numbers Authority [GANA]. The
	ztype is a unique identifier for the set crypographic functions of		ztype is a unique identifier for the set cryptographic functions of
	the zone and the format of the delegation record type. Any ztype		the zone and the format of the delegation record type. Any ztype
	MUST define the following set of cryptographic functions:		MUST define the following set of cryptographic functions:
	KeyGen() -> d, zk is a function to generate a new private key d and		KeyGen() -> d, zk is a function to generate a new private key d and
	the corresponding public zone key zk.		the corresponding public zone key zk.
	ZKDF(zk,label) -> zk' is a zone key derivation function which blinds		ZKDF(zk,label) -> zk' is a zone key derivation function which blinds
	a zone key zk using a label. zk and zk' must be unlinkable.		a zone key zk using a label. zk and zk' must be unlinkable.
	Furthermore, blinding zk with different values for the label must		Furthermore, blinding zk with different values for the label must
	result in different, unlinkable zk' values.		result in different, unlinkable zk' values.
	skipping to change at page 11, line 11 ¶		skipping to change at page 11, line 4 ¶
	verify the signature using the derived zone key zk' :=		verify the signature using the derived zone key zk' :=
	ZKDF(zk,label). The function returns a boolean value of "TRUE" if		ZKDF(zk,label). The function returns a boolean value of "TRUE" if
	the signature is valid, and otherwise "FALSE".		the signature is valid, and otherwise "FALSE".
	The cryptographic functions of the default ztypes are specified with		The cryptographic functions of the default ztypes are specified with
	their corresponding delegation records in Section 5.1. In order to		their corresponding delegation records in Section 5.1. In order to
	support cryptographic agility, additional ztypes MAY be defined in		support cryptographic agility, additional ztypes MAY be defined in
	the future which replace or update the default ztypes defined in this		the future which replace or update the default ztypes defined in this
	document. All ztypes MUST be registered as dedicated zone delegation		document. All ztypes MUST be registered as dedicated zone delegation
	record types in the GNU Name System Record Types registry (see		record types in the GNU Name System Record Types registry (see
	Section 10).		Section 10). When defining new record types the cryptographic
			security considerations of this document apply, in particular
			Section 9.3.
	4.1. Zone Top-Level Domain		4.1. Zone Top-Level Domain
	The zTLD is the Zone Top-Level Domain. It is a string which encodes		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		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		globally unique reference to a specific zone in the process of name
	resolution. It is created by encoding a binary concatenation of the		resolution. It is created by encoding a binary concatenation of the
	zone type and zone key (see Figure 3). The used encoding is a		zone type and zone key (see Figure 3). The used encoding is a
	variation of the Crockford Base32 encoding [CrockfordB32] called		variation of the Crockford Base32 encoding [CrockfordB32] called
	Base32GNS. The encoding and decoding symbols for Base32GNS including		Base32GNS. The encoding and decoding symbols for Base32GNS including
	skipping to change at page 12, line 4 ¶		skipping to change at page 11, line 34 ¶
	+-----+-----+-----+-----+ /		+-----+-----+-----+-----+ /
	/ /		/ /
	/ /		/ /
	Figure 3: The decoded binary representation of the zTLD		Figure 3: The decoded binary representation of the zTLD
	Consequently, a zTLD is encoded and decoded as follows:		Consequently, a zTLD is encoded and decoded as follows:
	zTLD := Base32GNS-Encode(ztype||zkey)		zTLD := Base32GNS-Encode(ztype||zkey)
	ztype||zkey := Base32GNS-Decode(zTLD)		ztype||zkey := Base32GNS-Decode(zTLD)
			where "||" is the concatenation operator.
	The zTLD can be used as-is as a rightmost label in a GNS name. If an		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		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		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		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		longer than 63 characters, the zTLD is divided into smaller labels
	separated by the label separator. Here, the most significant bytes		separated by the label separator. Here, the most significant bytes
	of the "ztype||zkey" concatenation must be contained in the rightmost		of the "ztype||zkey" concatenation must be contained in the rightmost
	label of the resulting string and the least significant bytes in the		label of the resulting string and the least significant bytes in the
	leftmost label of the resulting string. This allows the resolver to		leftmost label of the resulting string. This allows the resolver to
	determine the ztype and zTLD length from the rightmost label and to		determine the ztype and zTLD length from the rightmost label and to
	skipping to change at page 18, line 5 ¶		skipping to change at page 17, line 31 ¶
	SIZE denotes the 16-bit size of the DATA field in bytes and in		SIZE denotes the 16-bit size of the DATA field in bytes and in
	network byte order.		network byte order.
	FLAGS is a 16-bit resource record flags field (see below).		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		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		the GNS resource records as defined in Section 5 or a DNS record
	type as defined in [RFC1035] or any of the complementary		type as defined in [RFC1035] or any of the complementary
	standardized DNS resource record types. This value must be stored		standardized DNS resource record types. This value must be stored
	in network byte order. Note that values below 2^16 are reserved		in network byte order. Note that values below 2^16 are reserved
	for allocation via IANA [RFC6895], while values above 2^16 are		for 16-bit DNS Resorce Record types allocated by IANA [RFC6895].
	allocated by the GNUnet Assigned Numbers Authority [GANA].		Values above 2^16 are allocated by the GNUnet Assigned Numbers
			Authority [GANA].
	DATA the variable-length resource record data payload. The content		DATA the variable-length resource record data payload. The content
	is defined by the respective type of the resource record.		is defined by the respective type of the resource record.
	Flags indicate metadata surrounding the resource record. An		Flags indicate metadata surrounding the resource record. An
	application creating resource records MUST set all bits to 0 unless		application creating resource records MUST set all bits to 0 unless
	it wants to set the respective flag. As additional flags can be		it wants to set the respective flag. As additional flags can be
	defined in future protocol versions, if an application or		defined in future protocol versions, if an application or
	implementation encounters a flag which it does not recognize, it MUST		implementation encounters a flag which it does not recognize, it MUST
	be ignored. Any combination of the flags specified below are valid.		be ignored. Any combination of the flags specified below are valid.
	skipping to change at page 19, line 14 ¶		skipping to change at page 18, line 40 ¶
	if some zone delegation record types have been determined to be		if some zone delegation record types have been determined to be
	cryptographically insecure. Zone delegation records MUST NOT be		cryptographically insecure. Zone delegation records MUST NOT be
	stored and published under the apex label. A zone delegation record		stored and published under the apex label. A zone delegation record
	type value is the same as the respective ztype value. The ztype		type value is the same as the respective ztype value. The ztype
	defines the cryptographic primitives for the zone that is being		defines the cryptographic primitives for the zone that is being
	delegated to. A zone delegation record payload contains the public		delegated to. A zone delegation record payload contains the public
	key of the zone to delegate to. A zone delegation record MUST have		key of the zone to delegate to. A zone delegation record MUST have
	the CRITICAL flag set and MUST be the only non-supplemental record		the CRITICAL flag set and MUST be the only non-supplemental record
	under a label. There MAY be inactive records of the same type which		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.		have the SHADOW flag set in order to facilitate smooth key rollovers.
	flag set No other records are allowed.
			In the following, "||" is the concatenation operator of two byte
			strings. The algorithm specification uses character strings such as
			GNS labels or constant values. When used in concatenations or as
			input to functions the null-terminator of the character strings MUST
			NOT be included.
	5.1.1. PKEY		5.1.1. PKEY
	In GNS, a delegation of a label to a zone of type "PKEY" is		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		represented through a PKEY record. The PKEY DATA entry wire format
	can be found in Figure 9.		can be found in Figure 9.
	0 8 16 24 32 40 48 56		0 8 16 24 32 40 48 56
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
	| PUBLIC KEY |		| PUBLIC KEY |
	skipping to change at page 28, line 14 ¶		skipping to change at page 28, line 14 ¶
	5.3.1. LEHO		5.3.1. LEHO
	This record is used to provide a hint for LEgacy HOstnames:		This record is used to provide a hint for LEgacy HOstnames:
	Applications can use the GNS to lookup IPv4 or IPv6 addresses of		Applications can use the GNS to lookup IPv4 or IPv6 addresses of
	internet services. However, sometimes connecting to such services		internet services. However, sometimes connecting to such services
	does not only require the knowledge of an address and port, but also		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		requires the canonical DNS name of the service to be transmitted over
	the transport protocol. In GNS, legacy host name records provide		the transport protocol. In GNS, legacy host name records provide
	applications the DNS name that is required to establish a connection		applications the DNS name that is required to establish a connection
	to such a service. The most common use case is HTTP virtual hosting,		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		and TLS Server Name Indication [RFC6066], where a DNS name must be
	GNS name for the "Host"-header might not work as it might not be		supplied in the HTTP "Host"-header and the TLS handshake,
	globally unique. Furthermore, even if uniqueness is not an issue,		respectively. Using a GNS name in those cases might not work as it
	the legacy service might not even be aware of GNS.		might 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		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		resource record with an IPv4 or IPv6 address. A LEHO DATA entry is
	illustrated in Figure 15.		illustrated in Figure 15.
	0 8 16 24 32 40 48 56		0 8 16 24 32 40 48 56
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
	| LEGACY HOSTNAME |		| LEGACY HOSTNAME |
	/ /		/ /
	/ /		/ /
	skipping to change at page 29, line 49 ¶		skipping to change at page 29, line 49 ¶
	+-----------+-----------------------------------+		+-----------+-----------------------------------+
	| RECORD DATA |		| RECORD DATA |
	/ /		/ /
	/ /		/ /
	| |		| |
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
	Figure 17: The BOX DATA Wire Format.		Figure 17: The BOX DATA Wire Format.
	PROTO the 16-bit protocol number, e.g. 6 for TCP. Note that values		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		below 2^8 are reserved for 8-bit Internet Protocol numbers
	values above 2^8 are allocated by the GNUnet Assigned Numbers		allocated by IANA [RFC5237]. Values above 2^8 are allocated by
	Authority [GANA]. In network byte order.		the GNUnet Assigned Numbers Authority [GANA]. In network byte
			order.
	SVC the 16-bit service value of the boxed record. In case of TCP		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.		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		TYPE is the 32-bit record type of the boxed record. In network byte
	order.		order.
	RECORD DATA is a variable length field containing the "DATA" format		RECORD DATA is a variable length field containing the "DATA" format
	of TYPE as defined for the respective TYPE in DNS.		of TYPE as defined for the respective TYPE in DNS.
	6. Record Storage		6. Record Encoding
	Any API which allows storing a value under a 512-bit key and		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		retrieving one or more values from the key can be used by an
	implementation for record storage. To be useful, the API MUST permit		implementation for record storage. To be useful, the API MUST permit
	storing at least 176 byte values to be able to support the defined		storing at least 176 byte values to be able to support the defined
	zone delegation record encodings, and SHOULD allow at least 1024 byte		zone delegation record encodings, and SHOULD allow at least 1024 byte
	values. In the following, it is assumed that an implementation		values. In the following, it is assumed that an implementation
	realizes two procedures on top of a storage:		realizes two procedures on top of a storage:
	PUT(key,value)		PUT(key,value)
	skipping to change at page 43, line 21 ¶		skipping to change at page 43, line 21 ¶
	Ed25519 for PKEY records it can simply be introduced through a new		Ed25519 for PKEY records it can simply be introduced through a new
	record type. Zone administrators can then replace the delegation		record type. Zone administrators can then replace the delegation
	record type for future records. The old record type remains and		record type for future records. The old record type remains and
	zones can iteratively migrate to the updated zone keys. To ensure		zones can iteratively migrate to the updated zone keys. To ensure
	that implementations correctly generate an error message when		that implementations correctly generate an error message when
	encountering a ztype that they do not support, current and future		encountering a ztype that they do not support, current and future
	delegation records must always have the CRITICAL flag set.		delegation records must always have the CRITICAL flag set.
	9.3. Cryptography		9.3. Cryptography
			The following considerations provide background on the design choices
			of the ztypes specified in this document. When specifying new ztypes
			as per Section 4, the same considerations apply.
	GNS PKEY zone keys use ECDSA over Ed25519. This is an unconventional		GNS PKEY zone keys use ECDSA over Ed25519. This is an unconventional
	choice, as ECDSA is usually used with other curves. However,		choice, as ECDSA is usually used with other curves. However,
	standardized ECDSA curves are problematic for a range of reasons		standardized ECDSA curves are problematic for a range of reasons
	described in the Curve25519 and EdDSA papers [ed25519]. Using EdDSA		described in the Curve25519 and EdDSA papers [ed25519]. Using EdDSA
	directly is also not possible, as a hash function is used on the		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		private key which destroys the linearity that the key blinding in GNS
	depends upon. We are not aware of anyone suggesting that using		depends upon. We are not aware of anyone suggesting that using
	Ed25519 instead of another common curve of similar size would lower		Ed25519 instead of another common curve of similar size would lower
	the security of ECDSA. GNS uses 256-bit curves because that way the		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		encoded (public) keys fit into a single DNS label, which is good for
	skipping to change at page 44, line 23 ¶		skipping to change at page 44, line 27 ¶
	GNS names are UTF-8 strings. Consequently, GNS faces similar issues		GNS names are UTF-8 strings. Consequently, GNS faces similar issues
	with respect to name spoofing as DNS does for internationalized		with respect to name spoofing as DNS does for internationalized
	domain names. In DNS, attackers can register similar sounding or		domain names. In DNS, attackers can register similar sounding or
	looking names (see above) in order to execute phishing attacks. GNS		looking names (see above) in order to execute phishing attacks. GNS
	zone administrators must take into account this attack vector and		zone administrators must take into account this attack vector and
	incorporate rules in order to mitigate it.		incorporate rules in order to mitigate it.
	Further, DNS can be used to combat illegal content on the internet by		Further, DNS can be used to combat illegal content on the internet by
	having the respective domains seized by authorities. However, the		having the respective domains seized by authorities. However, the
	same mechanisms can also be abused in order to impose state		same mechanisms can also be abused in order to impose state
	censorship, which is one of the motivations behind GNS. Hence, such		censorship, which is one of the motivations behind GNS. In GNS, TLDs
	a seizure is, by design, difficult to impossible in GNS.		are not enumerable. By design, the start zone of the resolver is
			defined locally and hence such a seizure is difficult and ineffective
			in GNS.
	9.5. Zone Management		9.5. Zone Management
	In GNS, zone administrators need to manage and protect their zone		In GNS, zone administrators need to manage and protect their zone
	keys. Once a zone key is lost, it cannot be recovered or revoked.		keys. Once a zone key is lost, it cannot be recovered or revoked.
	Revocation messages can be pre-calculated if revocation is required		Revocation messages can be pre-calculated if revocation is required
	in case a zone key is lost. Zone administrators, and for GNS this		in case a zone key is lost. Zone administrators, and for GNS this
	includes end-users, are required to responsibly and diligently		includes end-users, are required to responsibly and diligently
	protect their cryptographic keys. GNS supports offline signing of		protect their cryptographic keys. GNS supports signing records in
	records.		advance ("offline") in order to support processes which aim to
			protect private keys such as air gaps.
	Similarly, users are required to manage their local start zone		Similarly, users are required to manage their local start zone
	configuration. In order to ensure integrity and availability or		configuration. In order to ensure integrity and availability or
	names, users must ensure that their local start zone information is		names, users must ensure that their local start zone information is
	not compromised or outdated. It can be expected that the processing		not compromised or outdated. It can be expected that the processing
	of zone revocations and an initial start zone is provided with a GNS		of zone revocations and an initial start zone is provided with a GNS
	implementation ("drop shipping"). Shipping an initial start zone		implementation ("drop shipping"). Shipping an initial start zone
	configuration effectively establishes a root zone. Extension and		configuration effectively establishes a root zone. Extension and
	customization of the zone is at the full discretion of the user.		customization of the zone is at the full discretion of the user.
	skipping to change at page 48, line 43 ¶		skipping to change at page 48, line 51 ¶
	This document makes no requests for IANA action. This section may be		This document makes no requests for IANA action. This section may be
	removed on publication as an RFC.		removed on publication as an RFC.
	12. Implementation and Deployment Status		12. Implementation and Deployment Status
	There are two implementations conforming to this specification		There are two implementations conforming to this specification
	written in C and Go, respectively. The C implementation as part of		written in C and Go, respectively. The C implementation as part of
	GNUnet [GNUnetGNS] represents the original and reference		GNUnet [GNUnetGNS] represents the original and reference
	implementation. The Go implementation [GoGNS] demonstrates how two		implementation. The Go implementation [GoGNS] demonstrates how two
	implementations of GNS are interoperable given that they are built on		implementations of GNS are interoperable if they are built on top of
	top of the same underlying DHT storage.		the same underlying DHT storage.
	Currently, the GNUnet peer-to-peer network [GNUnet] is an active		Currently, the GNUnet peer-to-peer network [GNUnet] is an active
	deployment of GNS on top of its [R5N] DHT. The [GoGNS]		deployment of GNS on top of its [R5N] DHT. The [GoGNS]
	implementation uses this deployment by building on top of the GNUnet		implementation uses this deployment by building on top of the GNUnet
	DHT services available on any GNUnet peer. It shows how GNS		DHT services available on any GNUnet peer. It shows how GNS
	implementations can attach to this existing deployment and		implementations can attach to this existing deployment and
	participate in name resolution as well as zone publication.		participate in name resolution as well as zone publication.
	The self-sovereign identity system re:claimID [reclaim] is using GNS		The self-sovereign identity system re:claimID [reclaim] is using GNS
	in order to selectively share identity attributes and attestations		in order to selectively share identity attributes and attestations
	skipping to change at page 52, line 5 ¶		skipping to change at page 52, line 12 ¶
	Unicode IDNA Compatibility Processing, Revision 27",		Unicode IDNA Compatibility Processing, Revision 27",
	August 2021, <https://www.unicode.org/reports/tr46>.		August 2021, <https://www.unicode.org/reports/tr46>.
	15. Informative References		15. Informative References
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements",		Rose, "DNS Security Introduction and Requirements",
	RFC 4033, DOI 10.17487/RFC4033, March 2005,		RFC 4033, DOI 10.17487/RFC4033, March 2005,
	<https://www.rfc-editor.org/info/rfc4033>.		<https://www.rfc-editor.org/info/rfc4033>.
			[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
			Extensions: Extension Definitions", RFC 6066,
			DOI 10.17487/RFC6066, January 2011,
			<https://www.rfc-editor.org/info/rfc6066>.
	[RFC7363] Maenpaa, J. and G. Camarillo, "Self-Tuning Distributed		[RFC7363] Maenpaa, J. and G. Camarillo, "Self-Tuning Distributed
	Hash Table (DHT) for REsource LOcation And Discovery		Hash Table (DHT) for REsource LOcation And Discovery
	(RELOAD)", RFC 7363, DOI 10.17487/RFC7363, September 2014,		(RELOAD)", RFC 7363, DOI 10.17487/RFC7363, September 2014,
	<https://www.rfc-editor.org/info/rfc7363>.		<https://www.rfc-editor.org/info/rfc7363>.
	[RFC8324] Klensin, J., "DNS Privacy, Authorization, Special Uses,		[RFC8324] Klensin, J., "DNS Privacy, Authorization, Special Uses,
	Encoding, Characters, Matching, and Root Structure: Time		Encoding, Characters, Matching, and Root Structure: Time
	for Another Look?", RFC 8324, DOI 10.17487/RFC8324,		for Another Look?", RFC 8324, DOI 10.17487/RFC8324,
	February 2018, <https://www.rfc-editor.org/info/rfc8324>.		February 2018, <https://www.rfc-editor.org/info/rfc8324>.
End of changes. 33 change blocks.
	109 lines changed or deleted		131 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/