< draft-vcelak-nsec5-04.txt		draft-vcelak-nsec5-05.txt >
	Network Working Group J. Vcelak		Network Working Group J. Vcelak
	Internet-Draft CZ.NIC		Internet-Draft CZ.NIC
	Intended status: Standards Track S. Goldberg		Intended status: Standards Track S. Goldberg
	Expires: September 08, 2017 Boston University		Expires: January 04, 2018 Boston University
	D. Papadopoulos		D. Papadopoulos
	University of Maryland		University of Maryland
	S. Huque		S. Huque
	Salesforce		Salesforce
	D. Lawrence		D. Lawrence
	Akamai Technologies		Akamai Technologies
	March 07, 2017		July 03, 2017
	NSEC5, DNSSEC Authenticated Denial of Existence		NSEC5, DNSSEC Authenticated Denial of Existence
	draft-vcelak-nsec5-04		draft-vcelak-nsec5-05
	Abstract		Abstract
	The Domain Name System Security Extensions (DNSSEC) introduced the		The Domain Name System Security Extensions (DNSSEC) introduced two
	NSEC resource record (RR) for authenticated denial of existence and		resource records (RR) for authenticated denial of existence: the NSEC
	the NSEC3 RR for hashed authenticated denial of existence. This		RR and the NSEC3 RR. This document introduces NSEC5 as an
	document introduces NSEC5 as an alternative mechanism for DNSSEC		alternative mechanism for DNSSEC authenticated denial of existence.
	authenticated denial of existence. NSEC5 uses verifiable random		NSEC5 uses verifiable random functions (VRFs) to prevent offline
	functions (VRFs) to prevent offline enumeration of zone contents.		enumeration of zone contents. NSEC5 also protects the integrity of
	NSEC5 also protects the integrity of the zone contents even if an		the zone contents even if an adversary compromises one of the
	adversary compromises one of the authoritative servers for the zone.		authoritative servers for the zone. Integrity is preserved because
	Integrity is preserved because NSEC5 does not require private zone-		NSEC5 does not require private zone-signing keys to be present on all
	signing keys to be present on all authoritative servers for the zone,		authoritative servers for the zone, in contrast to DNSSEC online
	in contrast to DNSSEC online signing schemes like NSEC3 White Lies.		signing schemes like NSEC3 White Lies.
			Ed note
			Text inside square brackets ([]) is additional background
			information, answers to frequently asked questions, general musings,
			etc. They will be removed before publication. This document is
			being collaborated on in GitHub at <https://github.com/fcelda/
			nsec5-draft>. The most recent version of the document, open issues,
			etc should all be available here. The authors gratefully accept pull
			requests.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 September 08, 2017.		This Internet-Draft will expire on January 04, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 41 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 5
	1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6		1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
	2. Backward Compatibility . . . . . . . . . . . . . . . . . . . 6		2. Backward Compatibility . . . . . . . . . . . . . . . . . . . 6
	3. How NSEC5 Works . . . . . . . . . . . . . . . . . . . . . . . 7		3. How NSEC5 Works . . . . . . . . . . . . . . . . . . . . . . . 7
	4. NSEC5 Algorithms . . . . . . . . . . . . . . . . . . . . . . 8		4. NSEC5 Algorithms . . . . . . . . . . . . . . . . . . . . . . 8
	5. The NSEC5KEY Resource Record . . . . . . . . . . . . . . . . 8		5. The NSEC5KEY Resource Record . . . . . . . . . . . . . . . . 9
	5.1. NSEC5KEY RDATA Wire Format . . . . . . . . . . . . . . . 8		5.1. NSEC5KEY RDATA Wire Format . . . . . . . . . . . . . . . 9
	5.2. NSEC5KEY RDATA Presentation Format . . . . . . . . . . . 9		5.2. NSEC5KEY RDATA Presentation Format . . . . . . . . . . . 9
	6. The NSEC5 Resource Record . . . . . . . . . . . . . . . . . . 9		6. The NSEC5 Resource Record . . . . . . . . . . . . . . . . . . 9
	6.1. NSEC5 RDATA Wire Format . . . . . . . . . . . . . . . . . 9		6.1. NSEC5 RDATA Wire Format . . . . . . . . . . . . . . . . . 9
	6.2. NSEC5 Flags Field . . . . . . . . . . . . . . . . . . . . 10		6.2. NSEC5 Flags Field . . . . . . . . . . . . . . . . . . . . 10
	6.3. NSEC5 RDATA Presentation Format . . . . . . . . . . . . . 10		6.3. NSEC5 RDATA Presentation Format . . . . . . . . . . . . . 11
	7. The NSEC5PROOF Resource Record . . . . . . . . . . . . . . . 11		7. The NSEC5PROOF Resource Record . . . . . . . . . . . . . . . 11
	7.1. NSEC5PROOF RDATA Wire Format . . . . . . . . . . . . . . 11		7.1. NSEC5PROOF RDATA Wire Format . . . . . . . . . . . . . . 11
	7.2. NSEC5PROOF RDATA Presentation Format . . . . . . . . . . 11		7.2. NSEC5PROOF RDATA Presentation Format . . . . . . . . . . 12
	8. Types of Authenticated Denial of Existence with NSEC5 . . . . 12		8. Types of Authenticated Denial of Existence with NSEC5 . . . . 12
	8.1. Name Error Responses . . . . . . . . . . . . . . . . . . 12		8.1. Name Error Responses . . . . . . . . . . . . . . . . . . 12
	8.2. No Data Responses . . . . . . . . . . . . . . . . . . . . 13		8.2. No Data Responses . . . . . . . . . . . . . . . . . . . . 13
	8.2.1. No Data Response, Opt-Out Not In Effect . . . . . . . 13		8.2.1. No Data Response, Opt-Out Not In Effect . . . . . . . 13
	8.2.2. No Data Response, Opt-Out In Effect . . . . . . . . . 13		8.2.2. No Data Response, Opt-Out In Effect . . . . . . . . . 14
	8.3. Wildcard Responses . . . . . . . . . . . . . . . . . . . 14		8.3. Wildcard Responses . . . . . . . . . . . . . . . . . . . 14
	8.4. Wildcard No Data Responses . . . . . . . . . . . . . . . 14		8.4. Wildcard No Data Responses . . . . . . . . . . . . . . . 14
	9. Authoritative Server Considerations . . . . . . . . . . . . . 15		9. Authoritative Server Considerations . . . . . . . . . . . . . 15
	9.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . 15		9.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . 15
	9.1.1. Precomputing Closest Provable Encloser Proofs . . . . 16		9.1.1. Precomputing Closest Provable Encloser Proofs . . . . 16
	9.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . 17		9.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . 17
	9.3. NSEC5KEY Rollover Mechanism . . . . . . . . . . . . . . . 17		9.3. NSEC5KEY Rollover Mechanism . . . . . . . . . . . . . . . 17
	9.4. Secondary Servers . . . . . . . . . . . . . . . . . . . . 18		9.4. Secondary Servers . . . . . . . . . . . . . . . . . . . . 18
	9.5. Zones Using Unknown NSEC5 Algorithms . . . . . . . . . . 18		9.5. Zones Using Unknown NSEC5 Algorithms . . . . . . . . . . 18
	9.6. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 18		9.6. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 18
	10. Resolver Considerations . . . . . . . . . . . . . . . . . . . 18		10. Resolver Considerations . . . . . . . . . . . . . . . . . . . 19
	11. Validator Considerations . . . . . . . . . . . . . . . . . . 19		11. Validator Considerations . . . . . . . . . . . . . . . . . . 19
	11.1. Validating Responses . . . . . . . . . . . . . . . . . . 19		11.1. Validating Responses . . . . . . . . . . . . . . . . . . 19
	11.2. Validating Referrals to Unsigned Subzones . . . . . . . 19		11.2. Validating Referrals to Unsigned Subzones . . . . . . . 20
	11.3. Responses With Unknown NSEC5 Algorithms . . . . . . . . 20		11.3. Responses With Unknown NSEC5 Algorithms . . . . . . . . 20
	12. Special Considerations . . . . . . . . . . . . . . . . . . . 20		12. Special Considerations . . . . . . . . . . . . . . . . . . . 20
	12.1. Transition Mechanism . . . . . . . . . . . . . . . . . . 20		12.1. Transition Mechanism . . . . . . . . . . . . . . . . . . 20
	12.2. Private NSEC5 keys . . . . . . . . . . . . . . . . . . . 20		12.2. Private NSEC5 keys . . . . . . . . . . . . . . . . . . . 20
	12.3. Domain Name Length Restrictions . . . . . . . . . . . . 20		12.3. Domain Name Length Restrictions . . . . . . . . . . . . 20
	13. Implementation Status . . . . . . . . . . . . . . . . . . . . 21		13. Implementation Status . . . . . . . . . . . . . . . . . . . . 21
	14. Performance Considerations . . . . . . . . . . . . . . . . . 21		14. Performance Considerations . . . . . . . . . . . . . . . . . 21
	15. Security Considerations . . . . . . . . . . . . . . . . . . . 21		15. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	15.1. Zone Enumeration Attacks . . . . . . . . . . . . . . . . 21		15.1. Zone Enumeration Attacks . . . . . . . . . . . . . . . . 21
	15.2. Compromise of the Private NSEC5 Key . . . . . . . . . . 21		15.2. Compromise of the Private NSEC5 Key . . . . . . . . . . 22
	15.3. Key Length Considerations . . . . . . . . . . . . . . . 22		15.3. Key Length Considerations . . . . . . . . . . . . . . . 22
	15.4. NSEC5 Hash Collisions . . . . . . . . . . . . . . . . . 22		15.4. NSEC5 Hash Collisions . . . . . . . . . . . . . . . . . 22
	16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23		17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
	18. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		18. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
	18.1. Normative References . . . . . . . . . . . . . . . . . . 23		18.1. Normative References . . . . . . . . . . . . . . . . . . 23
	18.2. Informative References . . . . . . . . . . . . . . . . . 25		18.2. Informative References . . . . . . . . . . . . . . . . . 25
	Appendix A. Elliptic Curve VRF . . . . . . . . . . . . . . . . . 26		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 26
	A.1. EC-VRF Auxiliary Functions . . . . . . . . . . . . . . . 27		A.1. Name Error Example . . . . . . . . . . . . . . . . . . . 27
	A.1.1. EC-VRF Hash To Curve . . . . . . . . . . . . . . . . 27		A.2. No Data Example . . . . . . . . . . . . . . . . . . . . . 28
	A.1.2. EC-VRF Hash Points . . . . . . . . . . . . . . . . . 28		A.3. Delegation to an Unsigned Zone in an Opt-Out span Example 29
	A.1.3. EC-VRF Decode Proof . . . . . . . . . . . . . . . . . 28		A.4. Wildcard Example . . . . . . . . . . . . . . . . . . . . 31
	A.2. EC-VRF Proving . . . . . . . . . . . . . . . . . . . . . 29		A.5. Wildcard No Data Example . . . . . . . . . . . . . . . . 32
	A.3. EC-VRF Proof To Hash . . . . . . . . . . . . . . . . . . 29		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 33
	A.4. EC-VRF Verifying . . . . . . . . . . . . . . . . . . . . 30
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 31
	1. Introduction		1. Introduction
	1.1. Rationale		1.1. Rationale
	NSEC5 provides an alternative mechanism for authenticated denial of		NSEC5 provides an alternative mechanism for authenticated denial of
	existence for the DNS Security Extensions (DNSSEC). NSEC5 has two		existence for the DNS Security Extensions (DNSSEC). NSEC5 has two
	key security properties. First, NSEC5 protects the integrity of the		key security properties. First, NSEC5 protects the integrity of the
	zone contents even if an adversary compromises one of the		zone contents even if an adversary compromises one of the
	authoritative servers for the zone. Second, NSEC5 prevents offline		authoritative servers for the zone. Second, NSEC5 prevents offline
	zone enumeration, where an adversary makes a small number of online		zone enumeration, where an adversary makes a small number of online
	DNS queries and then processes them offline in order to learn all of		DNS queries and then processes them offline in order to learn all of
	the names in a zone. Zone enumeration can be used to identify		the names in a zone. Zone enumeration can be used to identify
	routers, servers or other "things" that could then be targeted in		routers, servers or other "things" that could then be targeted in
	more complex attacks. An enumerated zone can also be a source of		more complex attacks. An enumerated zone can also be a source of
	skipping to change at page 6, line 4 ¶		skipping to change at page 5, line 46 ¶
	enumeration while still protecting the integrity of zone contents		enumeration while still protecting the integrity of zone contents
	against network attacks.		against network attacks.
	NSEC5 is not intended to replace NSEC or NSEC3. It is an alternative		NSEC5 is not intended to replace NSEC or NSEC3. It is an alternative
	mechanism for authenticated denial of existence. This document		mechanism for authenticated denial of existence. This document
	specifies NSEC5 based on the FIPS 186-3 P-256 elliptic curve and on		specifies NSEC5 based on the FIPS 186-3 P-256 elliptic curve and on
	the Ed25519 elliptic curve. A formal cryptographic proof of security		the Ed25519 elliptic curve. A formal cryptographic proof of security
	for elliptic curve (EC) NSEC5 is in [nsec5ecc].		for elliptic curve (EC) NSEC5 is in [nsec5ecc].
	1.2. Requirements		1.2. Requirements
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	1.3. Terminology		1.3. Terminology
	The reader is assumed to be familiar with the basic DNS and DNSSEC		The reader is assumed to be familiar with the basic DNS and DNSSEC
	concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034], and		concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034], and
	[RFC4035]; subsequent RFCs that update them in [RFC2136], [RFC2181],		[RFC4035]; subsequent RFCs that update them in [RFC2136], [RFC2181],
	[RFC2308], [RFC5155], and [RFC7129]; and DNS terms in [RFC7719].		[RFC2308], [RFC5155], and [RFC7129]; and DNS terms in [RFC7719].
			The reader should also be familiar with verifiable random functions
			(VRFs) as defined in [I-D.goldbe-vrf].
	The following terminology is used through this document:		The following terminology is used through this document:
	Base32hex: The "Base 32 Encoding with Extended Hex Alphabet" as		Base32hex: The "Base 32 Encoding with Extended Hex Alphabet" as
	specified in [RFC4648]. The padding characters ("=") are not used		specified in [RFC4648]. The padding characters ("=") are not used
	in the NSEC5 specification.		in the NSEC5 specification.
	Base64: The "Base 64 Encoding" as specified in [RFC4648].		Base64: The "Base 64 Encoding" as specified in [RFC4648].
	QNAME: The domain name being queried (query name).		QNAME: The domain name being queried (query name).
	skipping to change at page 6, line 39 ¶		skipping to change at page 6, line 39 ¶
	NSEC5 proof: A VRF proof. The holder of the private NSEC5 key		NSEC5 proof: A VRF proof. The holder of the private NSEC5 key
	(e.g., authoritative server) can compute the NSEC5 proof for an		(e.g., authoritative server) can compute the NSEC5 proof for an
	input domain name. Anyone who knows the public VRF key can verify		input domain name. Anyone who knows the public VRF key can verify
	that the NSEC5 proof corresponds to the input domain name.		that the NSEC5 proof corresponds to the input domain name.
	NSEC5 hash: A cryptographic digest of an NSEC5 proof. If the NSEC5		NSEC5 hash: A cryptographic digest of an NSEC5 proof. If the NSEC5
	proof is known, anyone can compute its corresponding NSEC5 hash.		proof is known, anyone can compute its corresponding NSEC5 hash.
	NSEC5 algorithm: A triple of VRF algorithms that compute an NSEC5		NSEC5 algorithm: A triple of VRF algorithms that compute an NSEC5
	proof, verify an NSEC5 proof, and process an NSEC5 proof to obtain		proof (VRF_prove), verify an NSEC5 proof (VRF_verify), and process
	its NSEC5 hash.		an NSEC5 proof to obtain its NSEC5 hash (VRF_proof2hash).
	2. Backward Compatibility		2. Backward Compatibility
	The specification describes a protocol change that is not backward		The specification describes a protocol change that is not backward
	compatible with [RFC4035] and [RFC5155]. An NSEC5-unaware resolver		compatible with [RFC4035] and [RFC5155]. An NSEC5-unaware resolver
	will fail to validate responses introduced by this document.		will fail to validate responses introduced by this document.
	To prevent NSEC5-unaware resolvers from attempting to validate the		To prevent NSEC5-unaware resolvers from attempting to validate the
	responses, new DNSSEC algorithms identifiers are introduced in		responses, new DNSSEC algorithms identifiers are introduced in
	Section 16 which alias existing algorithm numbers. The zones signed		Section 16 which alias existing algorithm numbers. The zones signed
	according to this specification MUST use only these algorithm		according to this specification MUST use only these algorithm
	identifiers, thus NSEC5-unaware resolvers will treat the zone as		identifiers, thus NSEC5-unaware resolvers will treat the zone as
	insecure.		insecure.
	3. How NSEC5 Works		3. How NSEC5 Works
	With NSEC5, the original domain name is hashed using the VRF using		With NSEC5, the original domain name is hashed using a VRF
	the following steps:		[I-D.goldbe-vrf] using the following steps:
	1. The domain name is processed using a VRF keyed with the private		1. The domain name is processed using a VRF keyed with the private
	NSEC5 key to obtain the NSEC5 proof. Anyone who knows the public		NSEC5 key to obtain the NSEC5 proof. Anyone who knows the public
	NSEC5 key, normally acquired via an NSEC5KEY RR, can verify that		NSEC5 key, normally acquired via an NSEC5KEY RR, can verify that
	a given NSEC5 proof corresponds to a given domain name.		a given NSEC5 proof corresponds to a given domain name.
	2. The NSEC5 proof is then processed using a publicly-computable VRF		2. The NSEC5 proof is then processed using a publicly-computable VRF
	proof-to-hash function to obtain the NSEC5 hash. The NSEC5 hash		proof2hash function to obtain the NSEC5 hash. The NSEC5 hash can
	can be computed by anyone who knows the input NSEC5 proof.		be computed by anyone who knows the input NSEC5 proof.
	The NSEC5 hash determines the position of a domain name in an NSEC5		The NSEC5 hash determines the position of a domain name in an NSEC5
	chain.		chain.
	To sign a zone, the private NSEC5 key is used to compute the NSEC5		To sign a zone, the private NSEC5 key is used to compute the NSEC5
	hashes for each name in the zone. These NSEC5 hashes are sorted in		hashes for each name in the zone. These NSEC5 hashes are sorted in
	canonical order [RFC4034] , and each consecutive pair forms an NSEC5		canonical order [RFC4034], and each consecutive pair forms an NSEC5
	RR. Each NSEC5 RR is signed offline using the private zone-signing		RR. Each NSEC5 RR is signed offline using the private zone-signing
	key. The resulting signed chain of NSEC5 RRs is provided to all		key. The resulting signed chain of NSEC5 RRs is provided to all
	authoritative servers for the zone, along with the private NSEC5 key.		authoritative servers for the zone, along with the private NSEC5 key.
	To prove non-existence of a particular domain name in response to a		To prove non-existence of a particular domain name in response to a
	query, the server uses the private NSEC5 key to compute the NSEC5		query, the server uses the private NSEC5 key to compute the NSEC5
	proof and NSEC5 hash corresponding to the queried name. The server		proof and NSEC5 hash corresponding to the queried name. The server
	then identifies the NSEC5 RR that covers the NSEC5 hash. The server		then identifies the NSEC5 RR that covers the NSEC5 hash, and responds
	then responds with the NSEC5 RR and its corresponding RRSIG signature		with this NSEC5 RR and its corresponding RRSIG signature RRset, as
	RRset, as well as a synthesized NSEC5PROOF RR that contains the NSEC5		well as a synthesized NSEC5PROOF RR that contains the NSEC5 proof
	proof corresponding to the queried name.		corresponding to the queried name.
	To validate the response, the client verifies the following items:		To validate the response, the client verifies the following items:
	o The client uses the public NSEC5 key, normally acquired from the		o The client uses the public NSEC5 key, normally acquired from the
	NSEC5KEY RR, to verify that the NSEC5 proof in the NSEC5PROOF RR		NSEC5KEY RR, to verify that the NSEC5 proof in the NSEC5PROOF RR
	corresponds to the queried name.		corresponds to the queried name.
	o The client uses the VRF proof-to-hash function to compute the		o The client uses the VRF proof2hash function to compute the NSEC5
	NSEC5 hash from the NSEC5 proof in the NSEC5PROOF RR. The client		hash from the NSEC5 proof in the NSEC5PROOF RR. The client
	verifies that the NSEC5 hash is covered by the NSEC5 RR.		verifies that the NSEC5 hash is covered by the NSEC5 RR.
	o The client verifies that the NSEC5 RR is validly signed by the		o The client verifies that the NSEC5 RR is validly signed by the
	RRSIG RRset.		RRSIG RRset.
	4. NSEC5 Algorithms		4. NSEC5 Algorithms
	The algorithms used for NSEC5 authenticated denial are independent of		The algorithms used for NSEC5 authenticated denial are independent of
	the algorithms used for DNSSEC signing. An NSEC5 algorithm defines		the algorithms used for DNSSEC signing. An NSEC5 algorithm defines
	how the NSEC5 proof and the NSEC5 hash are computed and validated.		how the NSEC5 proof and the NSEC5 hash are computed and validated.
	The input for the NSEC5 proof computation is an RR owner name in		The NSEC5 proof corresponding to a name is computed using
	[RFC4034] canonical wire format followed by a private NSEC5 key. The		ECVRF_prove(), as specified in [I-D.goldbe-vrf]. The input to
	output is an octet string.		ECVRF_prove() is a public NSEC5 key followed by a private NSEC5 key
			followed by an RR owner name in [RFC4034] canonical wire format. The
			output NSEC5 proof is an octet string.
	The input for the NSEC5 hash computation is the corresponding NSEC5		An NSEC5 hash corresponding to a name is computed from its NSEC5
	proof; the output is an octet string.		proof using ECVRF_proof2hash(), as specified in [I-D.goldbe-vrf].
			The input to VRF_proof2hash() is an NSEC5 proof as an octet string.
			The output NSEC5 hash is either an octet string, or INVALID.
	This document defines EC-P256-SHA256 NSEC5 algorithm as follows:		An NSEC5 proof for a name is verified using ECVRF_verify(), as
			specified in [I-D.goldbe-vrf]. The input is the NSEC5 public key,
			followed by an NSEC5 proof as an octet string, followed by an RR
			owner name in [RFC4034] canonical wire format. The output is either
			VALID or INVALID.
	o The NSEC5 proof is computed using an Elliptic Curve VRF with FIPS		This document defines the EC-P256-SHA256 NSEC5 algorithm as follows:
	186-3 P-256 curve. The proof computation and verification, and
	the proof-to-hash function are formally specified in Appendix A.
	The curve parameters are specified in [FIPS-186-3]
	(Section D.1.2.3) and [RFC5114] (Section 2.6).
	o The NSEC5 hash is the x-coordinate of the group element gamma from		o The VRF is the EC-VRF algorithm using the EC-VRF-P256-SHA256
	the NSEC5 proof (specified in Appendix A), encoded as a 32-octet		ciphersuite specified in [I-D.goldbe-vrf].
	unsigned integer in network byte order. In practice, the hash is
	a substring of the proof ranging from 2nd through 33th octet of
	the proof, inclusive.
	o The public key format to be used in the NSEC5KEY RR is defined in		o The public key format to be used in the NSEC5KEY RR is defined in
	Section 4 of [RFC6605] and thus is the same as the format used to		Section 4 of [RFC6605] and thus is the same as the format used to
	store ECDSA public keys in DNSKEY RRs.		store ECDSA public keys in DNSKEY RRs.
			[NOTE: This specification does not compress the elliptic curve
			point used for the public key! But we do compress curve points in
			every other place we use them with the P256 ECVRF. We could save
			31 octets in the NSEC5KEY record by encoding the public key with
			point compression!]
	This document defines EC-ED25519-SHA256 NSEC5 algorithm as follows:		This document defines the EC-ED25519-SHA256 NSEC5 algorithm as
			follows:
	o The NSEC5 proof and NSEC5 hash are the same as with EC-P256-SHA256		o The VRF is the EC-VRF algorithm using the EC-VRF-ED25519-SHA256
	but using Ed25519 elliptic curve with parameters defined in		ciphersuite specified in [I-D.goldbe-vrf].
	[RFC7748] Section 4.1.
	o The public key format to be used in the NSEC5KEY RR is defined in		o The public key format to be used in the NSEC5KEY RR is defined in
	Section 3 of [RFC8080] and thus is the same as the format used to		Section 3 of [RFC8080] and thus is the same as the format used to
	store Ed25519 public keys in DNSKEY RRs.		store Ed25519 public keys in DNSKEY RRs.
	5. The NSEC5KEY Resource Record		5. The NSEC5KEY Resource Record
	The NSEC5KEY RR stores a public NSEC5 key. The key allows clients to		The NSEC5KEY RR stores a public NSEC5 key. The key allows clients to
	validate an NSEC5 proof sent by a server.		validate an NSEC5 proof sent by a server.
	5.1. NSEC5KEY RDATA Wire Format		5.1. NSEC5KEY RDATA Wire Format
	The RDATA for NSEC5KEY RR is as shown below:
	1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3		The RDATA for the NSEC5KEY RR is as shown below:
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
	| Algorithm | Public Key /		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Algorithm | Public Key /
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Algorithm is a single octet identifying the NSEC5 algorithm.		Algorithm is a single octet identifying the NSEC5 algorithm.
	Public Key is a variable-sized field holding public key material for		Public Key is a variable-sized field holding public key material for
	NSEC5 proof verification.		NSEC5 proof verification.
	5.2. NSEC5KEY RDATA Presentation Format		5.2. NSEC5KEY RDATA Presentation Format
	The presentation format of the NSEC5KEY RDATA is as follows:		The presentation format of the NSEC5KEY RDATA is as follows:
	The Algorithm field is represented as an unsigned decimal integer.		The Algorithm field is represented as an unsigned decimal integer.
	The Public Key field is represented in Base64 encoding. Whitespace		The Public Key field is represented in Base64 encoding. Whitespace
	is allowed within the Base64 text.		is allowed within the Base64 text.
	6. The NSEC5 Resource Record		6. The NSEC5 Resource Record
	The NSEC5 RR provides authenticated denial of existence for an RRset		The NSEC5 RR provides authenticated denial of existence for an RRset
	or domain name. One NSEC5 RR represents one piece of an NSEC5 chain,		or domain name. One NSEC5 RR represents one piece of an NSEC5 chain,
	proving existence of the owner name and non-existence of other domain		proving existence of the owner name and non-existence of other domain
	names in the part of the hashed domain space covered until the next		names in the part of the hashed domain space that is covered until
	owner name hashed in the RDATA.		the next owner name hashed in the RDATA.
	6.1. NSEC5 RDATA Wire Format		6.1. NSEC5 RDATA Wire Format
	The RDATA for NSEC5 RR is as shown below:		The RDATA for the NSEC5 RR is as shown below:
	1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3		1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Key Tag | Flags | Next Length |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| Key Tag | Flags | Next Length |
	| Next Hashed Owner Name /		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| Next Hashed Owner Name /
	/ Type Bit Maps /		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		/ Type Bit Maps /
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Key Tag field contains the key tag value of the NSEC5KEY RR that		The Key Tag field contains the key tag value of the NSEC5KEY RR that
	validates the NSEC5 RR, in network byte order. The value is computed		validates the NSEC5 RR, in network byte order. The value is computed
	from the NSEC5KEY RDATA using the same algorithm, which is used to		from the NSEC5KEY RDATA using the same algorithm used to compute key
	compute key tag values for DNSKEY RRs. The algorithm is defined in		tag values for DNSKEY RRs. This algorithm is defined in [RFC4034].
	[RFC4034].
	The Flags field is a single octet. The meaning of individual bits of		The Flags field is a single octet. The meaning of individual bits of
	the field is defined in Section 6.2.		the field is defined in Section 6.2.
	The Next Length field is an unsigned single octet specifying the		The Next Length field is an unsigned single octet specifying the
	length of the Next Hashed Owner Name field in octets.		length of the Next Hashed Owner Name field in octets.
	The Next Hashed Owner Name field is a sequence of binary octets. It		The Next Hashed Owner Name field is a sequence of binary octets. It
	contains an NSEC5 hash of the next domain name in the NSEC5 chain.		contains an NSEC5 hash of the next domain name in the NSEC5 chain.
	Type Bit Maps is a variable-sized field encoding RR types present at		Type Bit Maps is a variable-sized field encoding RR types present at
	the original owner name matching the NSEC5 RR. The format of the		the original owner name matching the NSEC5 RR. The format of the
	field is equivalent to the format used in the NSEC3 RR, described in		field is equivalent to the format used in the NSEC3 RR, described in
	[RFC5155].		[RFC5155].
	6.2. NSEC5 Flags Field		6.2. NSEC5 Flags Field
	The following one-bit NSEC5 flags are defined:		The following one-bit NSEC5 flags are defined:
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| |W|O|		| |W|O|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	O - Opt-Out flag		O - Opt-Out flag
	W - Wildcard flag		W - Wildcard flag
	All the other flags are reserved for future use and MUST be zero.		All the other flags are reserved for future use and MUST be zero.
	The Opt-Out flag has the same semantics as in NSEC3. The definition		The Opt-Out flag has the same semantics as in NSEC3. The definition
	and considerations in [RFC5155] are valid, except that NSEC3 is		and considerations in [RFC5155] are valid, except that NSEC3 is
	replaced by NSEC5.		replaced by NSEC5.
	The Wildcard flag indicates that a wildcard synthesis is possible at		The Wildcard flag indicates that a wildcard synthesis is possible at
	the original domain name level (i.e., there is a wildcard node		the original domain name level (i.e., there is a wildcard node
	immediately descending from the immediate ancestor of the original		immediately descending from the immediate ancestor of the original
	domain name). The purpose of the Wildcard flag is to reduce the		domain name). The purpose of the Wildcard flag is to reduce the
	maximum number of RRs required for an authenticated denial of		maximum number of RRs required for an authenticated denial of
	existence proof, as originally described in [I-D.gieben-nsec4]		existence proof from (at most) three to (at most) two, as originally
	Section 7.2.1.		described in [I-D.gieben-nsec4] Section 7.2.1.
	6.3. NSEC5 RDATA Presentation Format		6.3. NSEC5 RDATA Presentation Format
	The presentation format of the NSEC5 RDATA is as follows:		The presentation format of the NSEC5 RDATA is as follows:
	The Key Tag field is represented as an unsigned decimal integer.		The Key Tag field is represented as an unsigned decimal integer.
	The Flags field is represented as an unsigned decimal integer.		The Flags field is represented as an unsigned decimal integer.
	The Next Length field is not represented.		The Next Length field is not represented.
	The Next Hashed Owner Name field is represented as a sequence of		The Next Hashed Owner Name field is represented as a sequence of
	case-insensitive Base32hex digits without any whitespace and without		case-insensitive Base32hex digits without any whitespace and without
	skipping to change at page 11, line 27 ¶		skipping to change at page 11, line 38 ¶
	used in NSEC3 RR, described in [RFC5155].		used in NSEC3 RR, described in [RFC5155].
	7. The NSEC5PROOF Resource Record		7. The NSEC5PROOF Resource Record
	The NSEC5PROOF record is not to be included in the zone file. The		The NSEC5PROOF record is not to be included in the zone file. The
	NSEC5PROOF record contains the NSEC5 proof, proving the position of		NSEC5PROOF record contains the NSEC5 proof, proving the position of
	the owner name in an NSEC5 chain.		the owner name in an NSEC5 chain.
	7.1. NSEC5PROOF RDATA Wire Format		7.1. NSEC5PROOF RDATA Wire Format
	The RDATA for NSEC5PROOF is shown below:		The RDATA for the NSEC5PROOF RR is shown below:
	1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3		1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Key Tag | Owner Name Hash /		| Key Tag | Owner Name Hash /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Key Tag field contains the key tag value of the NSEC5KEY RR that		Key Tag field contains the key tag value of the NSEC5KEY RR that
	validates the NSEC5PROOF RR, in network byte order.		validates the NSEC5PROOF RR, in network byte order.
	Owner Name Hash is a variable-sized sequence of binary octets		Owner Name Hash is a variable-sized sequence of binary octets
	encoding the NSEC5 proof of the owner name of the RR.		encoding the NSEC5 proof of the owner name of the RR.
	7.2. NSEC5PROOF RDATA Presentation Format		7.2. NSEC5PROOF RDATA Presentation Format
	The presentation format of the NSEC5PROOF RDATA is as follows:		The presentation format of the NSEC5PROOF RDATA is as follows:
	skipping to change at page 12, line 33 ¶		skipping to change at page 12, line 42 ¶
	If NSEC5 is said to match a domain name, the owner name of the NSEC5		If NSEC5 is said to match a domain name, the owner name of the NSEC5
	RR has to be equivalent to an NSEC5 hash of that domain name. If an		RR has to be equivalent to an NSEC5 hash of that domain name. If an
	NSEC5 RR is said to cover a domain name, the NSEC5 hash of the domain		NSEC5 RR is said to cover a domain name, the NSEC5 hash of the domain
	name must sort in canonical order between that NSEC5 RR's Owner Name		name must sort in canonical order between that NSEC5 RR's Owner Name
	and Next Hashed Owner Name.		and Next Hashed Owner Name.
	8.1. Name Error Responses		8.1. Name Error Responses
	Facts to prove:		Facts to prove:
	No RRset matching the QNAME exists.		Non-existence of the domain name that explictly matches the QNAME.
	No RRset matching the QNAME via wildcard expansion exists.
	The QNAME does not fall into a delegation.
	The QNAME does not fall into a DNAME redirection.		Non-existence of the wildcard that matches the QNAME.
	Authoritative server proofs:		Authoritative server proofs:
	NSEC5PROOF for closest encloser and matching NSEC5 RR.		NSEC5PROOF for closest encloser and matching NSEC5 RR.
	NSEC5PROOF for next closer name and covering NSEC5 RR.		NSEC5PROOF for next closer name and covering NSEC5 RR.
			The QNAME does not fall into a delegation.
			The QNAME does not fall into a DNAME redirection.
	Validator checks:		Validator checks:
	Closest encloser is in the zone.		Closest encloser is in the zone.
	Closest encloser has the Wildcard flag cleared.		The NSEC5 RR matching the closest encloser has its Wildcard flag
			cleared.
	Closest encloser does not have NS without SOA in the Type Bit Map.
	Closest encloser does not have DNAME in the Type Bit Maps.		The NSEC5 RR matching the closest encloser does not have NS
			without SOA in the Type Bit Map.
	Next closer name is derived correctly.		The NSEC5 RR matching the closest encloser does not have DNAME in
			the Type Bit Map.
	Next closer name is not in the zone.		Next closer name is not in the zone.
	8.2. No Data Responses		8.2. No Data Responses
	The processing of a No Data response for DS QTYPE differs if the Opt-		The processing of a No Data response for DS QTYPE differs if the Opt-
	Out is in effect. For DS QTYPE queries, the validator has two		Out is in effect. For DS QTYPE queries, the validator has two
	possible checking paths. The correct path can be simply decided by		possible checking paths. The correct path can be simply decided by
	inspecting if the NSEC5 RR in the response matches the QNAME.		inspecting if the NSEC5 RR in the response matches the QNAME.
	Note that the Opt-Out is valid only for DS QTYPE queries.		Note that the Opt-Out is valid only for DS QTYPE queries.
	8.2.1. No Data Response, Opt-Out Not In Effect		8.2.1. No Data Response, Opt-Out Not In Effect
	Facts to prove:		Facts to prove:
	An RRset matching the QNAME exists.		Existence of an RRset explicitly matching the QNAME.
	No QTYPE RRset matching the QNAME exists.		Non-existence of QTYPE RRset matching the QNAME.
	No CNAME RRset matching the QNAME exists.		Non-existence of CNAME RRset matching the QNAME.
	Authoritative server proofs:		Authoritative server proofs:
	NSEC5PROOF for the QNAME and matching NSEC5 RR.		NSEC5PROOF for the QNAME and matching NSEC5 RR.
	Validator checks:		Validator checks:
	The QNAME is in the zone.		QNAME is in the zone.
	The QNAME does not have QTYPE in the Type Bit Map.		NSEC5 RR matching the QNAME does not have QTYPE in Type Bit Map.
	The QNAME does not have CNAME in the Type Bit Map.		NSEC5 RR matching the QNAME does not have CNAME in Type Bit Map.
	8.2.2. No Data Response, Opt-Out In Effect		8.2.2. No Data Response, Opt-Out In Effect
	Facts to prove:		Facts to prove:
	The delegation is not covered by the NSEC5 chain.		The delegation is not covered by the NSEC5 chain.
	Authoritative server proofs:		Authoritative server proofs:
	NSEC5PROOF for closest provable encloser and matching NSEC5 RR.		NSEC5PROOF for closest provable encloser and matching NSEC5 RR.
	Validator checks:		Validator checks:
	Closest provable encloser is in zone.		Closest provable encloser is in zone.
	Closest provable encloser covers (not matches) the QNAME.		Closest provable encloser covers (not matches) the QNAME.
	Closest provable encloser has the Opt-Out flag set.		NSEC5 RR matching the closest provable encloser has Opt-Out flag
			set.
	8.3. Wildcard Responses		8.3. Wildcard Responses
	Facts to prove:		Facts to prove:
	No RRset matching the QNAME exists.		A signed positive response to the QNAME demonstrating the
			existence of the wildcard (label count in RRSIG is less than in
			QNAME), and also providing closest encloser name.
	No wildcard closer to the QNAME exists.		Non-existence of the domain name matching the QNAME.
	Authoritative server proofs:		Authoritative server proofs:
			A signed positive response for the wildcard expansion of the
			QNAME.
	NSEC5PROOF for next closer name and covering NSEC5 RR.		NSEC5PROOF for next closer name and covering NSEC5 RR.
	Validator checks:		Validator checks:
	Next closer name is derived correctly.
	Next closer name is not in the zone.		Next closer name is not in the zone.
	8.4. Wildcard No Data Responses		8.4. Wildcard No Data Responses
	Facts to prove:		Facts to prove:
	No RRset matching the QNAME exists.		The existence of the wildcard at the closest encloser to the
			QNAME.
	No QTYPE RRset exists at the wildcard matching the QNAME.
	No CNAME RRset exists at the wildcard matching the QNAME.
	No wildcard closer to the QNAME exists.		Non-existence of both the QTYPE and of the CNAME type that matches
			QNAME via wildcard expansion.
	Authoritative server proofs:		Authoritative server proofs:
	NSEC5PROOF for source of synthesis (i.e., wildcard at closest		NSEC5PROOF for source of synthesis (i.e., wildcard at closest
	encloser) and matching NSEC5 RR.		encloser) and matching NSEC5 RR.
	NSEC5PROOF for next closer name and covering NSEC5 RR.		NSEC5PROOF for next closer name and covering NSEC5 RR.
	Validator checks:		Validator checks:
	Source of synthesis matches the QNAME.		Closest encloser to the QNAME exists.
	Source of synthesis does not have QTYPE in the Type Bit Map.
	Source of synthesis does not have CNAME in the Type Bit Map.
	Next closer name is derived correctly.
	Next closer name is not in the zone.		NSEC5 RR matching the wildcard label prepended to the closest
			encloser, and which does not have the bits corresponding to the
			QTYPE and CNAME types set it the type bitmap.
	9. Authoritative Server Considerations		9. Authoritative Server Considerations
	9.1. Zone Signing		9.1. Zone Signing
	Zones using NSEC5 MUST satisfy the same properties as described in		Zones using NSEC5 MUST satisfy the same properties as described in
	Section 7.1 of [RFC5155], with NSEC3 replaced by NSEC5. In addition,		Section 7.1 of [RFC5155], with NSEC3 replaced by NSEC5. In addition,
	the following conditions MUST be satisfied as well:		the following conditions MUST be satisfied as well:
	o If the original owner name has a wildcard label immediately		o If the original owner name has a wildcard label immediately
	skipping to change at page 15, line 36 ¶		skipping to change at page 15, line 46 ¶
	o The zone apex MUST include an NSEC5KEY RRset containing a NSEC5		o The zone apex MUST include an NSEC5KEY RRset containing a NSEC5
	public key allowing verification of the current NSEC5 chain.		public key allowing verification of the current NSEC5 chain.
	The following steps describe one possible method to properly add		The following steps describe one possible method to properly add
	required NSEC5 related records into a zone. This is not the only		required NSEC5 related records into a zone. This is not the only
	such existing method.		such existing method.
	1. Select an algorithm for NSEC5. Generate the public and private		1. Select an algorithm for NSEC5. Generate the public and private
	NSEC5 keys.		NSEC5 keys.
	2. Add a NSEC5KEY RR into the zone apex containing the public NSEC5		2. Add an NSEC5KEY RR into the zone apex containing the public NSEC5
	key.		key.
	3. For each unique original domain name in the zone and each empty		3. For each unique original domain name in the zone and each empty
	non-terminal, add an NSEC5 RR. If Opt-Out is used, owner names		non-terminal, add an NSEC5 RR. If Opt-Out is used, owner names
	of unsigned delegations MAY be excluded.		of unsigned delegations MAY be excluded.
	a. The owner name of the NSEC5 RR is the NSEC5 hash of the		A. The owner name of the NSEC5 RR is the NSEC5 hash of the
	original owner name encoded in Base32hex without padding,		original owner name encoded in Base32hex without padding,
	prepended as a single label to the zone name.		prepended as a single label to the zone name.
	b. Set the Key Tag field to be the key tag corresponding to the		B. Set the Key Tag field to be the key tag corresponding to the
	public NSEC5 key.		public NSEC5 key.
	c. Clear the Flags field. If Opt-Out is being used, set the		C. Clear the Flags field. If Opt-Out is being used, set the Opt-
	Opt-Out flag. If there is a wildcard label directly		Out flag. If there is a wildcard label directly descending from
	descending from the original domain name, set the Wildcard		the original domain name, set the Wildcard flag. Note that the
	flag. Note that the wildcard can be an empty non-terminal		wildcard can be an empty non-terminal (i.e., the wildcard
	(i.e., the wildcard synthesis does not take effect and		synthesis does not take effect and therefore the flag is not to
	therefore the flag is not to be set).		be set).
	d. Set the Next Length field to a value determined by the used		D. Set the Next Length field to a value determined by the used
	NSEC5 algorithm. Leave the Next Hashed Owner Name field		NSEC5 algorithm. Leave the Next Hashed Owner Name field blank.
	blank.
	e. Set the Type Bit Maps field based on the RRsets present at		E. Set the Type Bit Maps field based on the RRsets present at the
	the original owner name.		original owner name.
	4. Sort the set of NSEC5 RRs into canonical order.		4. Sort the set of NSEC5 RRs into canonical order.
	5. For each NSEC5 RR, set the Next Hashed Owner Name field by using		5. For each NSEC5 RR, set the Next Hashed Owner Name field by using
	the owner name of the next NSEC5 RR in the canonical order. If		the owner name of the next NSEC5 RR in the canonical order. If
	the updated NSEC5 is the last NSEC5 RR in the chain, the owner		the updated NSEC5 is the last NSEC5 RR in the chain, the owner
	name of the first NSEC5 RR in the chain is used instead.		name of the first NSEC5 RR in the chain is used instead.
	The NSEC5KEY and NSEC5 RRs MUST have the same class as the zone SOA		The NSEC5KEY and NSEC5 RRs MUST have the same class as the zone SOA
	RR. Also the NSEC5 RRs SHOULD have the same TTL value as the SOA		RR. Also the NSEC5 RRs SHOULD have the same TTL value as the SOA
	minimum TTL field.		minimum TTL field.
	Notice that a use of Opt-Out is not indicated in the zone. This does		Notice that a use of Opt-Out is not indicated in the zone. This does
	not affect the ability of a server to prove insecure delegations.		not affect the ability of a server to prove insecure delegations.
	The Opt-Out MAY be part of the zone-signing tool configuration.		The Opt-Out MAY be part of the zone-signing tool configuration.
	9.1.1. Precomputing Closest Provable Encloser Proofs		9.1.1. Precomputing Closest Provable Encloser Proofs
	The worst-case scenario when answering a negative query with NSEC5		Per Section 8, the worst-case scenario when answering a negative
	requires authoritative server to respond with two NSEC5PROOF RRs and		query with NSEC5 requires authoritative server to respond with two
	two NSEC5 RRs. Per Section 8, one pair of NSEC5PROOF and NSEC5 RRs		NSEC5PROOF RRs and two NSEC5 RRs. One pair of NSEC5PROOF and NSEC5
	corresponds to the closest provable encloser, and the other pair		RRs corresponds to the closest provable encloser, and the other pair
	corresponds to the next closer name. The NSEC5PROOF corresponding to		corresponds to the next closer name. The NSEC5PROOF corresponding to
	the next closer name MUST be computed on the fly by the authoritative		the next closer name MUST be computed on the fly by the authoritative
	server when responding to the query. However, the NSEC5PROOF		server when responding to the query. However, the NSEC5PROOF
	corresponding to the closest provable encloser MAY be precomputed and		corresponding to the closest provable encloser MAY be precomputed and
	stored as part of zone signing.		stored as part of zone signing.
	Precomputing NSEC5PROOF RRs can halve the number of online		Precomputing NSEC5PROOF RRs can halve the number of online
	cryptographic computations required when responding to a negative		cryptographic computations required when responding to a negative
	query. NSEC5PROOF RRs MAY be precomputed as part of zone signing as		query. NSEC5PROOF RRs MAY be precomputed as part of zone signing as
	follows: For each NSEC5 RR, compute an NSEC5PROOF RR corresponding to		follows: For each NSEC5 RR, compute an NSEC5PROOF RR corresponding to
	skipping to change at page 17, line 15 ¶		skipping to change at page 17, line 25 ¶
	9.2. Zone Serving		9.2. Zone Serving
	This specification modifies DNSSEC-enabled DNS responses generated by		This specification modifies DNSSEC-enabled DNS responses generated by
	authoritative servers. In particular, it replaces use of NSEC or		authoritative servers. In particular, it replaces use of NSEC or
	NSEC3 RRs in such responses with NSEC5 RRs and adds NSEC5PROOF RRs.		NSEC3 RRs in such responses with NSEC5 RRs and adds NSEC5PROOF RRs.
	According to the type of a response, an authoritative server MUST		According to the type of a response, an authoritative server MUST
	include NSEC5 RRs in the response, as defined in Section 8. For each		include NSEC5 RRs in the response, as defined in Section 8. For each
	NSEC5 RR in the response, a corresponding RRSIG RRset and an		NSEC5 RR in the response, a corresponding RRSIG RRset and an
	NSEC5PROOF MUST be added as well. The NSEC5PROOF RR has its owner		NSEC5PROOF MUST be added as well. The NSEC5PROOF RR has its owner
	name set to the domain name required according to Section 8. The		name set to the domain name required according to the description in
	class and TTL of the NSEC5PROOF RR MUST be the same as the class and		Section 8. The class and TTL of the NSEC5PROOF RR MUST be the same
	TTL value of the corresponding NSEC5 RR. The RDATA payload of the		as the class and TTL value of the corresponding NSEC5 RR. The RDATA
	NSEC5PROOF is set according to the description in Section 7.1.		payload of the NSEC5PROOF is set according to the description in
			Section 7.1.
	Notice that the NSEC5PROOF owner name can be a wildcard (e.g., source		Notice that the NSEC5PROOF owner name can be a wildcard (e.g., source
	of synthesis proof in wildcard No Data responses). The name also		of synthesis proof in wildcard No Data responses). The name also
	always matches the domain name required for the proof while the NSEC5		always matches the domain name required for the proof while the NSEC5
	RR may only cover (not match) the name in the proof (e.g., closest		RR may only cover (not match) the name in the proof (e.g., closest
	encloser in Name Error responses).		encloser in Name Error responses).
	If NSEC5 is used, an answering server MUST use exactly one NSEC5		If NSEC5 is used, an answering server MUST use exactly one NSEC5
	chain for one signed zone.		chain for one signed zone.
	skipping to change at page 18, line 25 ¶		skipping to change at page 18, line 37 ¶
	zone.		zone.
	9.4. Secondary Servers		9.4. Secondary Servers
	This document does not define mechanism to distribute private NSEC5		This document does not define mechanism to distribute private NSEC5
	keys. See Section 15.2 for security considerations for private NSEC5		keys. See Section 15.2 for security considerations for private NSEC5
	keys.		keys.
	9.5. Zones Using Unknown NSEC5 Algorithms		9.5. Zones Using Unknown NSEC5 Algorithms
	Zones that are signed with unknown NSEC5 algorithm or an unavailable		Zones that are signed with an unknown NSEC5 algorithm or with an
	private NSEC5 key cannot be effectively served. Such zones SHOULD be		unavailable private NSEC5 key cannot be effectively served. Such
	rejected when loading and servers SHOULD respond with RCODE=2 (Server		zones SHOULD be rejected when loading and servers SHOULD respond with
	failure) when handling queries that would fall under such zones.		RCODE=2 (Server failure) when handling queries that would fall under
			such zones.
	9.6. Dynamic Updates		9.6. Dynamic Updates
	A zone signed using NSEC5 MAY accept dynamic updates [RFC2136]. The		A zone signed using NSEC5 MAY accept dynamic updates [RFC2136]. The
	changes to the zone MUST be performed in a way that ensures that the		changes to the zone MUST be performed in a way that ensures that the
	zone satisfies the properties specified in Section 9.1 at any time.		zone satisfies the properties specified in Section 9.1 at any time.
	The process described in [RFC5155] Section 7.5 describes how to		The process described in [RFC5155] Section 7.5 describes how to
	handle the issues surrounding the handling of empty non-terminals as		handle the issues surrounding the handling of empty non-terminals as
	well as Opt-Out.		well as Opt-Out.
	skipping to change at page 21, line 9 ¶		skipping to change at page 21, line 20 ¶
	without padding. When constructing the NSEC5 RR owner name, the		without padding. When constructing the NSEC5 RR owner name, the
	encoded hash is prepended to the name of the zone as a single label		encoded hash is prepended to the name of the zone as a single label
	which includes the length field of a single octet. The maximum		which includes the length field of a single octet. The maximum
	length of the zone name in wire format using the 256-bit hash is		length of the zone name in wire format using the 256-bit hash is
	therefore 202 octets (255 - 53).		therefore 202 octets (255 - 53).
	13. Implementation Status		13. Implementation Status
	NSEC5 has been implemented for the Knot DNS authoritative server		NSEC5 has been implemented for the Knot DNS authoritative server
	(version 1.6.4) and the Unbound recursive server (version 1.5.9).		(version 1.6.4) and the Unbound recursive server (version 1.5.9).
	The implementation did not introduce additional library dependencies;		The implementations did not introduce additional library
	all cryptographic primitives are already present in OpenSSL v1.0.2j,		dependencies; all cryptographic primitives are already present in
	which is used by both implementations. The implementation supports		OpenSSL v1.0.2j, which is used by both implementations. The
	the full spectrum of negative responses, (i.e., NXDOMAIN, NODATA,		implementations support the full spectrum of negative responses,
	Wildcard, Wildcard NODATA, and unsigned delegation). The		(i.e., NXDOMAIN, NODATA, Wildcard, Wildcard NODATA, and unsigned
	implementation supports the EC-P256-SHA256 algorithm. The code is		delegation) using the EC-P256-SHA256 algorithm. The code is
	deliberately modular, so that the EC-ED25519-SHA256 algorithm could		deliberately modular, so that the EC-ED25519-SHA256 algorithm could
	be implemented by using the Ed25519 elliptic curve [RFC8080] as a		be implemented by using the Ed25519 elliptic curve [RFC8080] as a
	drop-in replacement for the P256 elliptic curve. The authoritative		drop-in replacement for the P256 elliptic curve. The authoritative
	server implements the optimization from Section 9.1.1 to precompute		server implements the optimization from Section 9.1.1 to precompute
	the NSEC5PROOF RRs matching each NSEC5 record.		the NSEC5PROOF RRs matching each NSEC5 record.
	14. Performance Considerations		14. Performance Considerations
	The performance of NSEC5 has been evaluated in [nsec5ecc].		The performance of NSEC5 has been evaluated in [nsec5ecc].
	skipping to change at page 22, line 21 ¶		skipping to change at page 22, line 34 ¶
	15.3. Key Length Considerations		15.3. Key Length Considerations
	The NSEC5 key must be long enough to withstand attacks for as long as		The NSEC5 key must be long enough to withstand attacks for as long as
	the privacy of the zone contents is important. Even if the NSEC5 key		the privacy of the zone contents is important. Even if the NSEC5 key
	is rolled frequently, its length cannot be too short, because zone		is rolled frequently, its length cannot be too short, because zone
	privacy may be important for a period of time longer than the		privacy may be important for a period of time longer than the
	lifetime of the key. For example, an attacker might collect the		lifetime of the key. For example, an attacker might collect the
	entire chain of NSEC5 RR for the zone over one short period, and		entire chain of NSEC5 RR for the zone over one short period, and
	then, later (even after the NSEC5 key expires) perform an offline		then, later (even after the NSEC5 key expires) perform an offline
	dictionary attack that attempt to "reverse" the NSEC5 hash values		dictionary attack that attempts to reverse the NSEC5 hash values
	present in the NSEC5 RRs. This is in contrast to zone-signing and		present in the NSEC5 RRs. This is in contrast to zone-signing and
	key-signing keys used in DNSSEC; these keys, which ensure the		key-signing keys used in DNSSEC; these keys, which ensure the
	authenticity and integrity of the zone contents, need to remain		authenticity and integrity of the zone contents, need to remain
	secure only during their lifetime.		secure only during their lifetime.
	15.4. NSEC5 Hash Collisions		15.4. NSEC5 Hash Collisions
	If the NSEC5 hash of a QNAME collides with the NSEC5 hash of the		If the NSEC5 hash of a QNAME collides with the NSEC5 hash of the
	owner name of an NSEC5 RR, it will be impossible to prove the non-		owner name of an NSEC5 RR, it will be impossible to prove the non-
	existence of the colliding QNAME. However, the NSEC5 VRFs ensure		existence of the colliding QNAME. However, the NSEC5 VRFs ensure
	that obtaining such a collision is as difficult as obtaining a		that obtaining such a collision is as difficult as obtaining a
	collision in the SHA-256 hash function (requiring approximately 2^128		collision in the SHA-256 hash function, requiring approximately 2^128
	effort). Note that DNSSEC already relies on the assumption that a		effort. Note that DNSSEC already relies on the assumption that a
	cryptographic hash function is collision-resistant, since these hash		cryptographic hash function is collision-resistant, since these hash
	functions are used for generating and validating signatures and DS		functions are used for generating and validating signatures and DS
	RRs. See also the discussion on key lengths in [nsec5].		RRs. See also the discussion on key lengths in [nsec5].
	16. IANA Considerations		16. IANA Considerations
	This document updates the IANA registry "Domain Name System (DNS)		This document updates the IANA registry "Domain Name System (DNS)
	Parameters" in subregistry "Resource Record (RR) TYPEs", by defining		Parameters" in subregistry "Resource Record (RR) TYPEs", by defining
	the following new RR types:		the following new RR types:
	skipping to change at page 23, line 37 ¶		skipping to change at page 23, line 49 ¶
	(Weizmann Institute), Sachin Vasant (Cisco Systems), Leonid Reyzin		(Weizmann Institute), Sachin Vasant (Cisco Systems), Leonid Reyzin
	(Boston University), and Asaf Ziv (Weizmann Institute) who		(Boston University), and Asaf Ziv (Weizmann Institute) who
	contributed to the design of NSEC5. Ondrej Sury (CZ.NIC Labs), and		contributed to the design of NSEC5. Ondrej Sury (CZ.NIC Labs), and
	Duane Wessels (Verisign Labs) provided advice on the implementation		Duane Wessels (Verisign Labs) provided advice on the implementation
	of NSEC5, and assisted with evaluating its performance.		of NSEC5, and assisted with evaluating its performance.
	18. References		18. References
	18.1. Normative References		18.1. Normative References
			[FIPS-186-3]
			National Institute for Standards and Technology, "Digital
			Signature Standard (DSS)", FIPS PUB 186-3, June 2009.
			[I-D.goldbe-vrf]
			Goldberg, S., Papadopoulos, D., and J. Vcelak, "Verifiable
			Random Functions (VRFs)", draft-goldbe-vrf-01 (work in
			progress), June 2017.
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,		STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
	<http://www.rfc-editor.org/info/rfc1034>.		<http://www.rfc-editor.org/info/rfc1034>.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, November 1987.		specification", STD 13, RFC 1035, November 1987.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	skipping to change at page 25, line 7 ¶		skipping to change at page 25, line 27 ¶
	[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves		[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
	for Security", RFC 7748, DOI 10.17487/RFC7748, January		for Security", RFC 7748, DOI 10.17487/RFC7748, January
	2016, <http://www.rfc-editor.org/info/rfc7748>.		2016, <http://www.rfc-editor.org/info/rfc7748>.
	[RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security		[RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security
	Algorithm (EdDSA) for DNSSEC", RFC 8080, DOI 10.17487/		Algorithm (EdDSA) for DNSSEC", RFC 8080, DOI 10.17487/
	RFC8080, February 2017,		RFC8080, February 2017,
	<http://www.rfc-editor.org/info/rfc8080>.		<http://www.rfc-editor.org/info/rfc8080>.
	[FIPS-186-3]		18.2. Informative References
	National Institute for Standards and Technology, "Digital
	Signature Standard (DSS)", FIPS PUB 186-3, June 2009.
	[SECG1] Standards for Efficient Cryptography Group (SECG), "SEC 1:		[I-D.gieben-nsec4]
	Elliptic Curve Cryptography", Version 2.0, May 2009,		Gieben, R. and M. Mekking, "DNS Security (DNSSEC)
	<http://www.secg.org/sec1-v2.pdf>.		Authenticated Denial of Existence", draft-gieben-nsec4-01
			(work in progress), July 2012.
	18.2. Informative References		[MRV99] Michali, S., Rabin, M., and S. Vadhan, "Verifiable Random
			Functions", in FOCS, 1999.
	[nsec5] Goldberg, S., Naor, M., Papadopoulos, D., Reyzin, L.,		[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
	Vasant, S., and A. Ziv, "NSEC5: Provably Preventing DNSSEC		Operational Practices, Version 2", RFC 6781, DOI 10.17487/
	Zone Enumeration", in NDSS'15, July 2014, <https://		RFC6781, December 2012,
	eprint.iacr.org/2014/582.pdf>.		<http://www.rfc-editor.org/info/rfc6781>.
	[nsec5ecc]		[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of
	Papadopoulos, D., Wessels, D., Huque, S., Vcelak, J.,		Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
	Naor, M., Reyzin, L., and S. Goldberg, "Can NSEC5 be		February 2014, <http://www.rfc-editor.org/info/rfc7129>.
	Practical for DNSSEC Deployments?", in ePrint Cryptology
	Archive 2017/099, February 2017, <https://eprint.iacr.org/
	2017/099.pdf>.
	[nsec3gpu]		[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Wander, M., Schwittmann, L., Boelmann, C., and T. Weis,		Terminology", RFC 7719, DOI 10.17487/RFC7719, December
	"GPU-Based NSEC3 Hash Breaking", in IEEE Symp. Network		2015, <http://www.rfc-editor.org/info/rfc7719>.
	Computing and Applications (NCA), 2014.
	[nsec3walker]		[ldns-walk]
	Bernstein, D., "Nsec3 walker", 2011,		NLNetLabs, "ldns", 2015,
	<http://dnscurve.org/nsec3walker.html>.		<http://git.nlnetlabs.nl/ldns/tree/examples/ldns-walk.c>.
	[nmap-nsec-enum]		[nmap-nsec-enum]
	Bond, J., "nmap: dns-nsec-enum", 2011, <https://nmap.org/		Bond, J., "nmap: dns-nsec-enum", 2011, <https://nmap.org/
	nsedoc/scripts/dns-nsec-enum.html>.		nsedoc/scripts/dns-nsec-enum.html>.
	[nmap-nsec3-enum]		[nmap-nsec3-enum]
	Nikolic, A. and J. Bond, "nmap: dns-nsec3-enum", 2011,		Nikolic, A. and J. Bond, "nmap: dns-nsec3-enum", 2011,
	<https://nmap.org/nsedoc/scripts/dns-nsec3-enum.html>.		<https://nmap.org/nsedoc/scripts/dns-nsec3-enum.html>.
			[nsec3gpu]
			Wander, M., Schwittmann, L., Boelmann, C., and T. Weis,
			"GPU-Based NSEC3 Hash Breaking", in IEEE Symp. Network
			Computing and Applications (NCA), 2014.
	[nsec3map]		[nsec3map]
	anonion0, ., "nsec3map with John the Ripper plugin", 2015,		anonion0, "nsec3map with John the Ripper plugin", 2015,
	<https://github.com/anonion0/nsec3map.>.		<https://github.com/anonion0/nsec3map.>.
	[ldns-walk]		[nsec3walker]
	NLNetLabs, ., "ldns", 2015,		Bernstein, D., "Nsec3 walker", 2011,
	<http://git.nlnetlabs.nl/ldns/tree/examples/ldns-walk.c>.		<http://dnscurve.org/nsec3walker.html>.
	[MRV99] Michali, S., Rabin, M., and S. Vadhan, "Verifiable Random
	Functions", in FOCS, 1999.
	[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
	Operational Practices, Version 2", RFC 6781, DOI 10.17487/
	RFC6781, December 2012,
	<http://www.rfc-editor.org/info/rfc6781>.
	[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of		[nsec5] Goldberg, S., Naor, M., Papadopoulos, D., Reyzin, L.,
	Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,		Vasant, S., and A. Ziv, "NSEC5: Provably Preventing DNSSEC
	February 2014, <http://www.rfc-editor.org/info/rfc7129>.		Zone Enumeration", in NDSS'15, July 2014, <https://
			eprint.iacr.org/2014/582.pdf>.
	[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS		[nsec5ecc]
	Terminology", RFC 7719, DOI 10.17487/RFC7719, December		Papadopoulos, D., Wessels, D., Huque, S., Vcelak, J.,
	2015, <http://www.rfc-editor.org/info/rfc7719>.		Naor, M., Reyzin, L., and S. Goldberg, "Can NSEC5 be
			Practical for DNSSEC Deployments?", in ePrint Cryptology
			Archive 2017/099, February 2017, <https://eprint.iacr.org/
			2017/099.pdf>.
	[I-D.gieben-nsec4]		Appendix A. Examples
	Gieben, R. and M. Mekking, "DNS Security (DNSSEC)
	Authenticated Denial of Existence", draft-gieben-nsec4-01
	(work in progress), July 2012.
	Appendix A. Elliptic Curve VRF		We use small DNS zone to illustrate how denying responses are handled
			with NSEC5. For brevity, the class is not shown (defaults to IN) and
			the SOA record is shortened, resulting in the following zone file:
	The Elliptic Curve Verifiable Random Function (EC-VRF) operates in a		example.org. SOA ( ... )
	cyclic group G of prime order with generator g. The cyclic group G		example.org. NS a.example.org
	MAY be over the NIST-P256 elliptic curve, with curve parameters as
	specified in [FIPS-186-3] (Section D.1.2.3) and [RFC5114]
	(Section 2.6). The group G MAY alternatively be over the Ed25519
	elliptic curve with parameters defined in [RFC7748] (Section 4.1).
	The security of this VRF follows from the decisional Diffie-Hellman
	(DDH) assumption in the cyclic group G in the random oracle model.
	Formal security proofs for this VRF are in [nsec5ecc].
	Fixed options:		a.example.org. A 192.0.2.1
	G - elliptic curve (EC) group		c.example.org. A 192.0.2.2
			c.example.org. TXT "c record"
	Used parameters:		d.example.org. NS ns1.d.example.org
			ns1.d.example.org. A 192.0.2.4
	g^x - EC public key		g.example.org. A 192.0.2.1
			g.example.org. TXT "g record"
	x - EC private key		*.a.example.org. TXT "wildcard record"
	q - prime order of group G		Notice the delegation to an unsigned zone d.example.org served by
	g - generator of group G		ns1.d.example.org. (Note: if the d.example.org zone was signed, then
			the example.org zone have a DS record for d.example.org.)
	Used primitives:		Next we present example responses. All cryptographic values are
			shortened as indicated by "..." and ADDITIONAL sections have been
			removed.
	"" - empty octet string		A.1. Name Error Example
	|| - octet string concatenation		Consider a query for a type A record for a.b.c.example.org.
	p^k - EC point multiplication		The server must prove the following facts:
	p1*p2 - EC point addition		o Existence of closest encloser c.example.org.
	SHA256 - hash function SHA-256 as specified in [RFC6234]		o Non-existence of wildcard at closest encloser *.c.example.org.
	ECP2OS - EC point to octet string conversion with point		o Non-existence of next closer b.c.example.org.
	compression as specified in Section 2.3.3 of [SECG1]
	OS2ECP - octet string to EC point conversion with point		To do this, the server returns:
	compression as specified in Section 2.3.4 of [SECG1]
	A.1. EC-VRF Auxiliary Functions		;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 5937
	A.1.1. EC-VRF Hash To Curve		;; QUESTION SECTION:
			;; a.b.c.example.org. IN A
	ECVRF_hash_to_curve(m)		;; AUTHORITY SECTION:
			example.org. 3600 IN SOA a.example.org. hostmaster.example.org. (
			2010111214 21600 3600 604800 86400 )
	Input:		example.org. 3600 IN RRSIG SOA 16 2 3600 (
			20170412024301 20170313024301 5137 example.org. rT231b1rH... )
	m - value to be hashed, an octet string		This is an NSEC5PROOF RR for c.example.com. It's RDATA is the NSEC5
			proof corresponding to c.example.com. (NSEC5 proofs are randomized
			values, because NSEC5 proof values are computed uses the EC-VRF from
			[I-D.goldbe-vrf].) Per Section 9.1.1, this NSEC5PROOF RR may be
			precomputed.
	Output:		c.example.org. 86400 IN NSEC5PROOF 48566 Amgn22zUiZ9JVyaT...
	h - hashed value, EC point		This is a signed NSEC5 RR "matching" c.example.org, which proves the
			existence of closest encloser c.example.org. The NSEC5 RR has its
			owner name equal to the NSEC5 hash of c.example.org, which is O4K89V.
			(NSEC5 hash values are deterministic given the public NSEC5 key.)
			The NSEC5 RR also has its Wildcard flag cleared (see the "0" after
			the key ID 48566). This proves the non-existence of the wildcard at
			the closest encloser *.c.example.com. NSEC5 RRs are precomputed.
	Steps:		o4k89v.example.org. 86400 IN NSEC5 48566 0 0O49PI A TXT RRSIG
			o4k89v.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (
			20170412024301 20170313024301 5137 example.org. zDNTSMQNlz... )
	1. c = 0		This is an NSEC5PROOF RR for b.c.example.org. It's RDATA is the
			NSEC5 proof corresponding to b.c.example.com. This NSEC5PROOF RR
			must be computed on-the-fly.
	2. C = I2OSP(c, 4)		b.c.example.org. 86400 IN NSEC5PROOF 48566 AuvvJqbUcEs8sCpY...
	3. xc = SHA256(m || C)		This is a signed NSEC5 RR "covering" b.c.example.org, which proves
			the non-existence of the next closer name b.c.example.org The NSEC5
			hash of b.c.example.org, which is AO5OF, sorts in canonical order
			between the "covering" NSEC5 RR's Owner Name (which is 0O49PI) and
			Next Hashed Owner Name (which is BAPROH).
	4. p = 0x02 || xc		0o49pi.example.org. 86400 IN NSEC5 48566 0 BAPROH (
			NS SOA RRSIG DNSKEY NSEC5KEY )
	5. If p is not a valid octet string representing encoded compressed		0o49pi.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (
	point in G:		20170412024301 20170313024301 5137 example.org. 4HT1uj1YlMzO)
	a. c = c + 1		[TODO: Add discussion of CNAME and DNAME to the example?]
	b. Go to step 2.
	6. h = OS2ECP(p)		A.2. No Data Example
	7. Output h		Consider a query for a type MX record for c.example.org.
	A.1.2. EC-VRF Hash Points		The server must prove the following facts:
	ECVRF_hash_points(p_1, p_2, ..., p_n)		o Existence of c.example.org. for any type other than MX or CNAME
	Input:		To do this, the server returns:
	p_x - EC point in G		;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 38781
	Output:		;; QUESTION SECTION:
			;; c.example.org. IN MX
	h - hash value, integer between 0 and 2^128-1		;; AUTHORITY SECTION:
			example.org. 3600 IN SOA a.example.org. hostmaster.example.org. (
			2010111214 21600 3600 604800 86400 )
	Steps:		example.org. 3600 IN RRSIG SOA 16 2 3600 20170412024301 20170313024301 5137 example.org. /rT231b1rH/p
	1. P = ""		This is an NSEC5PROOF RR for c.example.com. Its RDATA corresponds to
			the NSEC5 proof for c.example.com. which is a randomized value. Per
			Section 9.1.1, this NSEC5PROOF RR may be precomputed.
	2. for p in [p_1, p_2, ... p_n]:		c.example.org. 86400 IN NSEC5PROOF 48566 Amgn22zUiZ9JVyaT
	P = P || ECP2OS(p)
	3. h' = SHA256(P)		This is a signed NSEC5 RR "matching" c.example.org. with CNAME and MX
			Type Bits cleared and its TXT Type Bit set. This NSEC5 RR has its
			owner name equal to the NSEC5 hash of c.example.org. This proves the
			existence of c.example.org. for a type other than MX and CNAME.
			NSEC5 RR are precomputed.
	4. h = OS2IP(first 16 octets of h')		o4k89v.example.org. 86400 IN NSEC5 48566 0 0O49PI A TXT RRSIG
	5. Output h		o4k89v.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (
			20170412024301 20170313024301 5137 example.org. zDNTSMQNlz/J)
	A.1.3. EC-VRF Decode Proof		A.3. Delegation to an Unsigned Zone in an Opt-Out span Example
	ECVRF_decode_proof(pi)		Consider a query for a type A record for foo.d.example.org.
	Input:		Here, d.example.org is a delegation to an unsigned zone, which sits
			within an Opt-Out span.
	pi - VRF proof, octet string (81 octets)		The server must prove the following facts:
	Output:		o Non-existence of signature on next closer name d.example.org.
	gamma - EC point		o Opt-out bit is set in NSEC5 record covering next closer name
			d.example.org.
	c - integer between 0 and 2^128-1		o Existence of closest provable encloser example.org
	s - integer between 0 and 2^256-1		To do this, the server returns:
	Steps:		;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 45866
	1. let gamma', c', s' be pi split after 33-rd and 49-th octet		;; QUESTION SECTION:
			;; foo.d.example.org. IN A
	2. gamma = OS2ECP(gamma')		;; AUTHORITY SECTION:
			d.example.org. 3600 IN NS ns1.d.example.org.
	3. c = OS2IP(c')		This is an NSEC5PROOF RR for d.example.org. It's RDATA is the NSEC5
			proof corresponding to d.example.org. This NSEC5PROOF RR is computed
			on the fly.
	4. s = OS2IP(s')		d.example.org. 86400 IN NSEC5PROOF 48566 A9FpmeH79q7g6VNW
	5. Output gamma, c, and s		This is a signed NSEC5 RR "covering" d.example.org with its Opt-out
			bit set (see the "1" after the key ID 48566). The NSEC5 hash of
			d.example.org (which is BLE8LR) sorts in canonical order between the
			"covering" NSEC5 RR's Owner Name (BAPROH) and Next Hashed Owner Name
			(JQBMG4). This proves that no signed RR exists for d.example.org,
			but that the zone might contain a unsigned RR for a name whose NSEC5
			hash sorts in canonical order between BAPROH and JQBMG4.
	A.2. EC-VRF Proving		baproh.example.org. 86400 IN NSEC5 48566 1 JQBMG4 A TXT RRSIG
	ECVRF_PROVE(g^x, x, alpha)		baproh.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (
			20170412024301 20170313024301 5137 example.org. fjTcoRKgdML1)
	Input:		This is an NSEC5PROOF RR for example.com. It's RDATA is the NSEC5
			proof corresponding to example.com. Per Section 9.1.1, this
			NSEC5PROOF RR may be precomputed.
	g^x - EC public key		example.org. 86400 IN NSEC5PROOF 48566 AjwsPCJZ8zH/D0Tr
	x - EC private key		This is a signed NSEC5 RR "matching" example.org which proves the
			existence of a signed RRs for example.org. This NSEC5 RR has its
			owner name equal to the NSEC5 hash of example.org which is 0O49PI.
			NSEC5 RR are precomputed.
	alpha - message to be signed, octet string		0o49pi.example.org. 86400 IN NSEC5 48566 0 BAPROH (
			NS SOA RRSIG DNSKEY NSEC5KEY)
	Output:		0o49pi.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (
			20170412034216 20170313034216 5137 example.org. 4HT1uj1YlMzO)
	pi - VRF proof, octet string (81 octets)		A.4. Wildcard Example
	beta - VRF hash, octet string (32 octets)		Consider a query for a type TXT record for foo.a.example.org.
	Steps:		The server must prove the following facts:
	1. h = ECVRF_hash_to_curve(alpha)		o Existence of the TXT record for the wildcard *.a.example.org
	2. gamma = h^x		o Non-existence of the next closer name foo.a.example.org.
	3. choose a nonce k from [0, q-1]		To do this, the server returns:
	4. c = ECVRF_hash_points(g, h, g^x, h^x, g^k, h^k)		;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 53731
	5. s = k - c*q mod q		;; QUESTION SECTION:
			;; foo.a.example.org. IN TXT
	6. pi = ECP2OS(gamma) || I2OSP(c, 16) || I2OSP(s, 32)		This is a signed TXT record for the wildcard at a.example.org (number
			of labels is set to 3 in the RRSIG record).
	7. beta = h2(gamma)		;; ANSWER SECTION:
			foo.a.example.org. 3600 IN TXT "wildcard record"
	8. Output pi and beta		foo.a.example.org. 3600 IN RRSIG TXT 16 3 3600 (
			20170412024301 20170313024301 5137 example.org. aeaLgZ8sk+98)
	A.3. EC-VRF Proof To Hash		;; AUTHORITY SECTION:
	ECVRF_PROOF2HASH(gamma)		example.org. 3600 IN NS a.example.org.
	Input:		example.org. 3600 IN RRSIG NS 16 2 3600 (
			20170412024301 20170313024301 5137 example.org. 8zuN0h2x5WyF)
	gamma - VRF proof, EC point in G with coordinates (x, y)		This is an NSEC5PROOF RR for foo.a.example.org. This NSEC5PROOF RR
			must be computed on-the-fly.
	Output:		foo.a.example.org. 86400 IN NSEC5PROOF 48566 AjqF5FGGVso40Lda
	beta - VRF hash, octet string (32 octets)		This is a signed NSEC5 RR "covering" foo.a.example.org. The NSEC5
			hash of foo.a.example.org is FORDMO and sorts in canonical order
			between the NSEC5 RR's Owner Name (which is BAPROH) and Next Hashed
			Owner Name (which is JQBMG4). This proves the non-existence of the
			next closer name foo.a.example.com. NSEC5 RRs are precomputed.
	Steps:		baproh.example.org. 86400 IN NSEC5 48566 1 JQBMG4 A TXT RRSIG
			baproh.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (
			20170412024301 20170313024301 5137 example.org. fjTcoRKgdML1
	1. beta = I2OSP(x, 32)		A.5. Wildcard No Data Example
	2. Output beta		Consider a query for a type MX record for foo.a.example.org.
	Note: Because of the format of the compressed form of an elliptic		The server must prove the following facts:
	curve, the hash can be retrieved from an encoded gamma simply by
	omitting the first octet of the gamma.
	A.4. EC-VRF Verifying		o Existence of wildcard at closest encloser *.a.example.org. for any
			type other than MX or CNAME.
	ECVRF_VERIFY(g^x, pi, alpha)		o Non-existence of the next closer name foo.a.example.org.
	Input:		To do this, the server returns:
	g^x - EC public key		;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 17332
	pi - VRF proof, octet string		;; QUESTION SECTION:
			;; foo.a.example.org. IN MX
	alpha - message to verify, octet string		;; AUTHORITY SECTION:
			example.org. 3600 IN SOA a.example.org. hostmaster.example.org. (
			2010111214 21600 3600 604800 86400 )
	Output:		example.org. 3600 IN RRSIG SOA 16 2 3600 (
			20170412024301 20170313024301 5137 example.org. /rT231b1rH/p )
	"valid signature" or "invalid signature"		This is an NSEC5PROOF RR for *.a.example.com, with RDATA equal to the
			NSEC5 proof for *.a.example.com. Per Section 9.1.1, this NSEC5PROOF
			RR may be precomputed.
	beta - VRF hash, octet string (32 octets)		*.a.example.org. 86400 IN NSEC5PROOF 48566 Aq38RWWPhbs/vtih
	Steps:		This is a signed NSEC5 RR "matching" *.a.example.org with its CNAME
			and MX Type Bits cleared and its TXT Type Bit set. This NSEC5 RR has
			its owner name equal to the NSEC5 hash of *.a.example.org. NSEC5 RRs
			are precomputed.
	1. gamma, c, s = ECVRF_decode_proof(pi)		mpu6c4.example.org. 86400 IN NSEC5 48566 0 O4K89V TXT RRSIG
	2. u = (g^x)^c * g^s		mpu6c4.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (
			20170412024301 20170313024301 5137 example.org. m3I75ttcWwVC )
	3. h = ECVRF_hash_to_curve(alpha)		This is an NSEC5PROOF RR for foo.a.example.com. This NSEC5PROOF RR
			must be computed on-the-fly.
	4. v = gamma^c * h^s		foo.a.example.org. 86400 IN NSEC5PROOF 48566 AjqF5FGGVso40Lda
	5. c' = ECVRF_hash_points(g, h, g^x, gamma, u, v)
	6. beta = ECVRF_PROOF2HASH(gamma)		This is a signed NSEC5 RR "covering" foo.a.example.org. The NSEC5
			hash of foo.a.example.org is FORDMO, and sorts in canonical order
			between this covering NSEC5 RR's Owner Name (which is BAPROH) and
			Next Hashed Owner Name (which is JQBMG4). This proves the existence
			of the wildcard at closest encloser *.a.example.org. for any type
			other than MX or CNAME. NSEC5 RRs are precomputed.
	7. If c and c' are the same, output "valid signature"; else output		baproh.example.org. 86400 IN NSEC5 48566 1 JQBMG4 A TXT RRSIG
	"invalid signature". Output beta.
	[[TODO: check validity of gamma before hashing]]		baproh.example.org. 86400 IN RRSIG NSEC5 16 3 86400 (
			20170412024301 20170313024301 5137 example.org. fjTcoRKgdML1 )
	Appendix B. Change Log		Appendix B. Change Log
	Note to RFC Editor: if this document does not obsolete an existing		Note to RFC Editor: if this document does not obsolete an existing
	RFC, please remove this appendix before publication as an RFC.		RFC, please remove this appendix before publication as an RFC.
	pre 00 - initial version of the document submitted to mailing list		pre 00 - initial version of the document submitted to mailing list
	only		only
	00 - fix NSEC5KEY rollover mechanism, clarify NSEC5PROOF RDATA,		00 - fix NSEC5KEY rollover mechanism, clarify NSEC5PROOF RDATA,
	skipping to change at page 31, line 39 ¶		skipping to change at page 33, line 48 ¶
	03 - Mention precomputed NSEC5PROOF Values in Performance		03 - Mention precomputed NSEC5PROOF Values in Performance
	Considerations section.		Considerations section.
	04 - Edit Rationale, How NSEC5 Works, and Security Consideration		04 - Edit Rationale, How NSEC5 Works, and Security Consideration
	sections for clarity. Edit Zone Signing section, adding		sections for clarity. Edit Zone Signing section, adding
	precomputation of NSEC5PROOFs. Remove RSA-based NSEC5		precomputation of NSEC5PROOFs. Remove RSA-based NSEC5
	specification. Rewrite Performance Considerations and		specification. Rewrite Performance Considerations and
	Implementation Status sections.		Implementation Status sections.
			05 - Remove appendix specifying VRFs and add reference to
			[I-D.goldbe-vrf]. Add Appendix A.
	Authors' Addresses		Authors' Addresses
	Jan Vcelak		Jan Vcelak
	CZ.NIC		CZ.NIC
	Milesovska 1136/5		Milesovska 1136/5
	Praha 130 00		Praha 130 00
	CZ		CZ
	EMail: jan.vcelak@nic.cz		EMail: jan.vcelak@nic.cz
	Sharon Goldberg		Sharon Goldberg
	Boston University		Boston University
	111 Cummington St, MCS135		111 Cummington St, MCS135
	Boston, MA 02215		Boston, MA 02215
	USA		USA
	EMail: goldbe@cs.bu.edu		EMail: goldbe@cs.bu.edu
	Dimitrios Papadopoulos		Dimitrios Papadopoulos
	University of Maryland		University of Maryland
	8223 Paint Branch Dr		8223 Paint Branch Dr
	College Park, MD 20740		College Park, MD 20740
	USA		USA
	EMail: dipapado@umd.edu		EMail: dipapado@umd.edu
	Shumon Huque		Shumon Huque
	Salesforce		Salesforce
	2550 Wasser Terrace		2550 Wasser Terr
	Herndon, VA 20171		Herndon, VA 20171
	USA		USA
	EMail: shuque@gmail.com		EMail: shuque@gmail.com
	David C Lawrence		David C Lawrence
	Akamai Technologies		Akamai Technologies
	150 Broadway		150 Broadway
	Boston, MA 02142-1054		Boston, MA 02142-1054
	USA		USA
End of changes. 194 change blocks.
	341 lines changed or deleted		445 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/