< draft-vcelak-nsec5-06.txt		draft-vcelak-nsec5-07.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: July 6, 2018 Boston University		Expires: December 30, 2018 Boston University
	D. Papadopoulos		D. Papadopoulos
	HKUST		HKUST
	S. Huque		S. Huque
	Salesforce		Salesforce
	D. Lawrence		D. Lawrence
	Akamai Technologies		Akamai Technologies
	January 2, 2018		June 28, 2018
	NSEC5, DNSSEC Authenticated Denial of Existence		NSEC5, DNSSEC Authenticated Denial of Existence
	draft-vcelak-nsec5-06		draft-vcelak-nsec5-07
	Abstract		Abstract
	The Domain Name System Security Extensions (DNSSEC) introduced two		The Domain Name System Security Extensions (DNSSEC) introduced two
	resource records (RR) for authenticated denial of existence: the NSEC		resource records (RR) for authenticated denial of existence: the NSEC
	RR and the NSEC3 RR. This document introduces NSEC5 as an		RR and the NSEC3 RR. This document introduces NSEC5 as an
	alternative mechanism for DNSSEC authenticated denial of existence.		alternative mechanism for DNSSEC authenticated denial of existence.
	NSEC5 uses verifiable random functions (VRFs) to prevent offline		NSEC5 uses verifiable random functions (VRFs) to prevent offline
	enumeration of zone contents. NSEC5 also protects the integrity of		enumeration of zone contents. NSEC5 also protects the integrity of
	the zone contents even if an adversary compromises one of the		the zone contents even if an adversary compromises one of the
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	authoritative servers for the zone, in contrast to DNSSEC online		authoritative servers for the zone, in contrast to DNSSEC online
	signing schemes like NSEC3 White Lies.		signing schemes like NSEC3 White Lies.
	Ed note		Ed note
	Text inside square brackets ([]) is additional background		Text inside square brackets ([]) is additional background
	information, answers to frequently asked questions, general musings,		information, answers to frequently asked questions, general musings,
	etc. They will be removed before publication. This document is		etc. They will be removed before publication. This document is
	being collaborated on in GitHub at <https://github.com/fcelda/		being collaborated on in GitHub at <https://github.com/fcelda/
	nsec5-draft>. The most recent version of the document, open issues,		nsec5-draft>. The most recent version of the document, open issues,
	etc should all be available here. The authors gratefully accept pull		etc should all be available there. The authors gratefully accept
	requests.		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 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 July 6, 2018.		This Internet-Draft will expire on December 30, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	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 . . . . . . . . . . . . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . . . . 9		5. The NSEC5KEY Resource Record . . . . . . . . . . . . . . . . 9
	5.1. NSEC5KEY RDATA Wire Format . . . . . . . . . . . . . . . 9		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 . . . . . . . . . . . . . . . . . 10
	6.2. NSEC5 Flags Field . . . . . . . . . . . . . . . . . . . . 10		6.2. NSEC5 Flags Field . . . . . . . . . . . . . . . . . . . . 10
	6.3. NSEC5 RDATA Presentation Format . . . . . . . . . . . . . 11		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 . . . . . . . . . . 12		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 . . . . . . . . . 14		8.2.2. No Data Response, Opt-Out In Effect . . . . . . . . . 14
	skipping to change at page 5, line 20 ¶		skipping to change at page 5, line 20 ¶
	| Unsigned | NO | NO | YES | NO |		| Unsigned | NO | NO | YES | NO |
	| NSEC | YES | YES | NO | NO |		| NSEC | YES | YES | NO | NO |
	| NSEC3 | YES | YES | NO | NO |		| NSEC3 | YES | YES | NO | NO |
	| NSEC3-WL | YES | NO | YES | YES |		| NSEC3-WL | YES | NO | YES | YES |
	| NSEC5 | YES | YES | YES | YES |		| NSEC5 | YES | YES | YES | YES |
	+----------+-------------+---------------+----------------+---------+		+----------+-------------+---------------+----------------+---------+
	NSEC5 prevents offline zone enumeration and also protects integrity		NSEC5 prevents offline zone enumeration and also protects integrity
	even if a zone's authoritative server is compromised. To do this,		even if a zone's authoritative server is compromised. To do this,
	NSEC5 replaces the unkeyed cryptographic hash function used in NSEC3		NSEC5 replaces the unkeyed cryptographic hash function used in NSEC3
	with a verifiable random function (VRF) [I-D.goldbe-vrf] [MRV99]. A		with a verifiable random function (VRF) [I-D.irtf-cfrg-vrf] [MRV99].
	VRF is the public-key version of a keyed cryptographic hash. Only		A VRF is the public-key version of a keyed cryptographic hash. Only
	the holder of the private VRF key can compute the hash, but anyone		the holder of the private VRF key can compute the hash, but anyone
	with public VRF key can verify the correctness of the hash.		with public VRF key can verify the correctness of the hash.
	The public VRF key is distributed in an NSEC5KEY RR, similar to a		The public VRF key is distributed in an NSEC5KEY RR, similar to a
	DNSKEY RR, and is used to verify NSEC5 hash values. The private VRF		DNSKEY RR, and is used to verify NSEC5 hash values. The private VRF
	key is present on all authoritative servers for the zone, and is used		key is present on all authoritative servers for the zone, and is used
	to compute hash values. For every query that elicits a negative		to compute hash values. For every query that elicits a negative
	response, the authoritative server hashes the query on the fly using		response, the authoritative server hashes the query on the fly using
	the private VRF key, and also returns the corresponding precomputed		the private VRF key, and also returns the corresponding precomputed
	NSEC5 record(s). In contrast to the online signing approach		NSEC5 record(s). In contrast to the online signing approach
	skipping to change at page 5, line 44 ¶		skipping to change at page 5, line 44 ¶
	Like online signing approaches, NSEC5 requires the authoritative		Like online signing approaches, NSEC5 requires the authoritative
	server to perform online public key cryptographic operations for		server to perform online public key cryptographic operations for
	every query eliciting a denying response. This is necessary; [nsec5]		every query eliciting a denying response. This is necessary; [nsec5]
	proved that online cryptography is required to prevent offline zone		proved that online cryptography is required to prevent offline zone
	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 VRFs in [I-D.goldbe-vrf] over the FIPS		specifies NSEC5 based on the VRFs in [I-D.irtf-cfrg-vrf] over the
	186-3 P-256 elliptic curve and over the the Ed25519 elliptic curve.		FIPS 186-3 P-256 elliptic curve and over the the Ed25519 elliptic
	A formal cryptographic proof of security for NSEC5 is in [nsec5ecc].		curve. A formal cryptographic proof of security for 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		The reader should also be familiar with verifiable random functions
	(VRFs) as defined in [I-D.goldbe-vrf].		(VRFs) as defined in [I-D.irtf-cfrg-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 7, line 10 ¶		skipping to change at page 7, line 15 ¶
	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 a VRF		With NSEC5, the original domain name is hashed using a VRF
	[I-D.goldbe-vrf] using the following steps:		[I-D.irtf-cfrg-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
	proof2hash function to obtain the NSEC5 hash. The NSEC5 hash can		proof2hash function to obtain the NSEC5 hash. The NSEC5 hash can
	be computed by anyone who knows the input NSEC5 proof.		be computed by anyone who knows the input NSEC5 proof.
	skipping to change at page 8, line 12 ¶		skipping to change at page 8, line 15 ¶
	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 NSEC5 proof corresponding to a name is computed using		The NSEC5 proof corresponding to a name is computed using
	ECVRF_prove(), as specified in [I-D.goldbe-vrf]. The input to		ECVRF_prove(), as specified in [I-D.irtf-cfrg-vrf]. The input to
	ECVRF_prove() is a public NSEC5 key followed by a private NSEC5 key		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		followed by an RR owner name in [RFC4034] canonical wire format. The
	output NSEC5 proof is an octet string.		output NSEC5 proof is an octet string.
	An NSEC5 hash corresponding to a name is computed from its NSEC5		An NSEC5 hash corresponding to a name is computed from its NSEC5
	proof using ECVRF_proof2hash(), as specified in [I-D.goldbe-vrf].		proof using ECVRF_proof2hash(), as specified in [I-D.irtf-cfrg-vrf].
	The input to VRF_proof2hash() is an NSEC5 proof as an octet string.		The input to VRF_proof2hash() is an NSEC5 proof as an octet string.
	The output NSEC5 hash is either an octet string, or INVALID.		The output NSEC5 hash is either an octet string, or INVALID.
	An NSEC5 proof for a name is verified using ECVRF_verify(), as		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,		specified in [I-D.irtf-cfrg-vrf]. The input is the NSEC5 public key,
	followed by an NSEC5 proof as an octet string, followed by an RR		followed by an NSEC5 proof as an octet string, followed by an RR
	owner name in [RFC4034] canonical wire format. The output is either		owner name in [RFC4034] canonical wire format. The output is either
	VALID or INVALID.		VALID or INVALID.
	This document defines the EC-P256-SHA256 NSEC5 algorithm as follows:		This document defines the EC-P256-SHA256 NSEC5 algorithm as follows:
	o The VRF is the EC-VRF algorithm using the EC-VRF-P256-SHA256		o The VRF is the ECVRF algorithm using the ECVRF-P256-SHA256
	ciphersuite specified in [I-D.goldbe-vrf].		ciphersuite specified in [I-D.irtf-cfrg-vrf].
	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		[NOTE: This specification does not compress the elliptic curve
	point used for the public key, but we do compress curve points in		point used for the public key, but we do compress curve points in
	every other place we use them. The NSEC5KEY record can be shrunk		every other place we use them. The NSEC5KEY record can be shrunk
	by 31 additional octets by encoding the public key with point		by 31 additional octets by encoding the public key with point
	compression.]		compression.]
	This document defines the EC-ED25519-SHA256 NSEC5 algorithm as		This document defines the EC-ED25519-SHA512 NSEC5 algorithm as
	follows:		follows:
	o The VRF is the EC-VRF algorithm using the EC-VRF-ED25519-SHA256		o The VRF is the EC-VRF algorithm using the ECVRF-ED25519-SHA512
	ciphersuite specified in [I-D.goldbe-vrf].		ciphersuite specified in [I-D.irtf-cfrg-vrf].
	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.
			[NOTE: Could alternatively have the EC-ED25519-SHA512 NSEC5
			ciphersuite use the EC-VRF-ED25519-SHA512-ELLIGATOR2 ciphersuite
			specified in [I-D.irtf-cfrg-vrf].]
	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 the NSEC5KEY RR is as shown below:		The RDATA for the 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		1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
	skipping to change at page 24, line 13 ¶		skipping to change at page 24, line 13 ¶
	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]		[FIPS-186-3]
	National Institute for Standards and Technology, "Digital		National Institute for Standards and Technology, "Digital
	Signature Standard (DSS)", FIPS PUB 186-3, June 2009.		Signature Standard (DSS)", FIPS PUB 186-3, June 2009.
	[I-D.goldbe-vrf]		[I-D.irtf-cfrg-vrf]
	Goldberg, S., Papadopoulos, D., and J. Vcelak, "Verifiable		Goldberg, S., Reyzin, L., Papadopoulos, D., and J. Vcelak,
	Random Functions (VRFs)", draft-goldbe-vrf-01 (work in		"Verifiable Random Functions (VRFs)", draft-irtf-cfrg-
	progress), June 2017.		vrf-01 (work in progress), March 2018.
	[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,
	<https://www.rfc-editor.org/info/rfc1034>.		<https://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, DOI 10.17487/RFC1035,		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
	November 1987, <https://www.rfc-editor.org/info/rfc1035>.		November 1987, <https://www.rfc-editor.org/info/rfc1035>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 28, line 20 ¶		skipping to change at page 28, line 20 ¶
	;; AUTHORITY SECTION:		;; AUTHORITY SECTION:
	example.org. 3600 IN SOA a.example.org. hostmaster.example.org. (		example.org. 3600 IN SOA a.example.org. hostmaster.example.org. (
	2010111214 21600 3600 604800 86400 )		2010111214 21600 3600 604800 86400 )
	example.org. 3600 IN RRSIG SOA 16 2 3600 (		example.org. 3600 IN RRSIG SOA 16 2 3600 (
	20170412024301 20170313024301 5137 example.org. rT231b1rH... )		20170412024301 20170313024301 5137 example.org. rT231b1rH... )
	This is an NSEC5PROOF RR for c.example.com. It's RDATA is the NSEC5		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		proof corresponding to c.example.com. (NSEC5 proofs are randomized
	values, because NSEC5 proof values are computed uses the EC-VRF from		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		[I-D.irtf-cfrg-vrf].) Per Section 9.1.1, this NSEC5PROOF RR may be
	precomputed.		precomputed.
	c.example.org. 86400 IN NSEC5PROOF 48566 Amgn22zUiZ9JVyaT...		c.example.org. 86400 IN NSEC5PROOF 48566 Amgn22zUiZ9JVyaT...
	This is a signed NSEC5 RR "matching" c.example.org, which proves the		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		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.		owner name equal to the NSEC5 hash of c.example.org, which is O4K89V.
	(NSEC5 hash values are deterministic given the public NSEC5 key.)		(NSEC5 hash values are deterministic given the public NSEC5 key.)
	The NSEC5 RR also has its Wildcard flag cleared (see the "0" after		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 key ID 48566). This proves the non-existence of the wildcard at
	skipping to change at page 34, line 5 ¶		skipping to change at page 34, line 5 ¶
	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		05 - Remove appendix specifying VRFs and add reference to draft-
	[I-D.goldbe-vrf]. Add Appendix A.		goldbe-vrf. Add Appendix A.
	06 - Editorial changes. Minor updates to Section 8.1.		06 - Editorial changes. Minor updates to Section 8.1.
			07 - Updated reference to [I-D.irtf-cfrg-vrf], updated VRF
			ciphersuites.
	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
End of changes. 22 change blocks.
	30 lines changed or deleted		38 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/