< draft-vcelak-nsec5-00.txt		draft-vcelak-nsec5-01.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 24, 2015 Boston University		Expires: March 24, 2016 Boston University
	March 23, 2015		September 21, 2015
	NSEC5, DNSSEC Authenticated Denial of Existence		NSEC5, DNSSEC Authenticated Denial of Existence
	draft-vcelak-nsec5-00		draft-vcelak-nsec5-01
	Abstract		Abstract
	The Domain Name System Security (DNSSEC) Extensions introduced the		The Domain Name System Security (DNSSEC) Extensions introduced the
	NSEC resource record (RR) for authenticated denial of existence and		NSEC resource record (RR) for authenticated denial of existence and
	the NSEC3 for hashed authenticated denial of existence. The NSEC RR		the NSEC3 for hashed authenticated denial of existence. The NSEC RR
	allows for the entire zone contents to be enumerated if a server is		allows for the entire zone contents to be enumerated if a server is
	queried for carefully chosen domain names; N queries suffice to		queried for carefully chosen domain names; N queries suffice to
	enumerate a zone containing N names. The NSEC3 RR adds domain-name		enumerate a zone containing N names. The NSEC3 RR adds domain-name
	hashing, which makes the zone enumeration harder, but not impossible.		hashing, which makes the zone enumeration harder, but not impossible.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 24, 2015.		This Internet-Draft will expire on March 24, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 30 ¶		skipping to change at page 2, line 30 ¶
	4. NSEC5 Algorithms . . . . . . . . . . . . . . . . . . . . . . 6		4. NSEC5 Algorithms . . . . . . . . . . . . . . . . . . . . . . 6
	5. The NSEC5KEY Resource Record . . . . . . . . . . . . . . . . 7		5. The NSEC5KEY Resource Record . . . . . . . . . . . . . . . . 7
	5.1. NSEC5KEY RDATA Wire Format . . . . . . . . . . . . . . . 7		5.1. NSEC5KEY RDATA Wire Format . . . . . . . . . . . . . . . 7
	5.2. NSEC5KEY RDATA Presentation Format . . . . . . . . . . . 7		5.2. NSEC5KEY RDATA Presentation Format . . . . . . . . . . . 7
	6. The NSEC5 Resource Record . . . . . . . . . . . . . . . . . . 7		6. The NSEC5 Resource Record . . . . . . . . . . . . . . . . . . 7
	6.1. NSEC5 RDATA Wire Format . . . . . . . . . . . . . . . . . 7		6.1. NSEC5 RDATA Wire Format . . . . . . . . . . . . . . . . . 7
	6.2. NSEC5 Flags Field . . . . . . . . . . . . . . . . . . . . 8		6.2. NSEC5 Flags Field . . . . . . . . . . . . . . . . . . . . 8
	6.3. NSEC5 RDATA Presentation Format . . . . . . . . . . . . . 9		6.3. NSEC5 RDATA Presentation Format . . . . . . . . . . . . . 9
	7. The NSEC5PROOF Resource Record . . . . . . . . . . . . . . . 9		7. The NSEC5PROOF Resource Record . . . . . . . . . . . . . . . 9
	7.1. NSEC5PROOF RDATA Wire Format . . . . . . . . . . . . . . 9		7.1. NSEC5PROOF RDATA Wire Format . . . . . . . . . . . . . . 9
	7.2. NSEC5PROOF RDATA Presentation Format . . . . . . . . . . 9		7.2. NSEC5PROOF RDATA Presentation Format . . . . . . . . . . 10
	8. NSEC5 Proofs . . . . . . . . . . . . . . . . . . . . . . . . 10		8. NSEC5 Proofs . . . . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Name Error Responses . . . . . . . . . . . . . . . . . . 10		8.1. Name Error Responses . . . . . . . . . . . . . . . . . . 10
	8.2. No Data Responses . . . . . . . . . . . . . . . . . . . . 11		8.2. No Data Responses . . . . . . . . . . . . . . . . . . . . 11
	8.2.1. No Data Response, Opt-Out Not In Effect . . . . . . . 11		8.2.1. No Data Response, Opt-Out Not In Effect . . . . . . . 11
	8.2.2. No Data Response, Opt-Out In Effect . . . . . . . . . 11		8.2.2. No Data Response, Opt-Out In Effect . . . . . . . . . 12
	8.3. Wildcard Responses . . . . . . . . . . . . . . . . . . . 12		8.3. Wildcard Responses . . . . . . . . . . . . . . . . . . . 12
	8.4. Wildcard No Data Responses . . . . . . . . . . . . . . . 12		8.4. Wildcard No Data Responses . . . . . . . . . . . . . . . 12
	9. Authoritative Server Considerations . . . . . . . . . . . . . 13		9. Authoritative Server Considerations . . . . . . . . . . . . . 13
	9.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . 13		9.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . 13
	9.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . 14		9.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . 14
	9.3. NSEC5KEY Rollover Mechanism . . . . . . . . . . . . . . . 15		9.3. NSEC5KEY Rollover Mechanism . . . . . . . . . . . . . . . 15
	9.4. Secondary Servers . . . . . . . . . . . . . . . . . . . . 15		9.4. Secondary Servers . . . . . . . . . . . . . . . . . . . . 16
	9.5. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 16		9.5. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 16
	9.6. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 16		9.6. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 16
	10. Resolver Considerations . . . . . . . . . . . . . . . . . . . 16		10. Resolver Considerations . . . . . . . . . . . . . . . . . . . 16
	11. Validator Considerations . . . . . . . . . . . . . . . . . . 16		11. Validator Considerations . . . . . . . . . . . . . . . . . . 16
	11.1. Validating Responses . . . . . . . . . . . . . . . . . . 16		11.1. Validating Responses . . . . . . . . . . . . . . . . . . 16
	11.2. Validating Referrals to Unsigned Subzones . . . . . . . 17		11.2. Validating Referrals to Unsigned Subzones . . . . . . . 17
	11.3. Responses With Unknown Hash Algorithms . . . . . . . . . 17		11.3. Responses With Unknown Hash Algorithms . . . . . . . . . 17
	12. Special Considerations . . . . . . . . . . . . . . . . . . . 17		12. Special Considerations . . . . . . . . . . . . . . . . . . . 18
	12.1. Transition Mechanism . . . . . . . . . . . . . . . . . . 17		12.1. Transition Mechanism . . . . . . . . . . . . . . . . . . 18
	12.2. NSEC5 Private Keys . . . . . . . . . . . . . . . . . . . 18		12.2. NSEC5 Private Keys . . . . . . . . . . . . . . . . . . . 18
	12.3. Domain Name Length Restrictions . . . . . . . . . . . . 18		12.3. Domain Name Length Restrictions . . . . . . . . . . . . 18
	13. Performance Considerations . . . . . . . . . . . . . . . . . 19		13. Performance Considerations . . . . . . . . . . . . . . . . . 19
	14. Security Considerations . . . . . . . . . . . . . . . . . . . 19		13.1. Performance of Cryptographic Operations . . . . . . . . 19
	14.1. Zone Enumeration Attacks . . . . . . . . . . . . . . . . 19		13.2. Authoritative Server Startup . . . . . . . . . . . . . . 20
	14.2. Hash Collisions . . . . . . . . . . . . . . . . . . . . 19		13.3. NSEC5 Answer Generating and Processing . . . . . . . . . 21
	14.3. Compromise of the Private NSEC5 Key . . . . . . . . . . 19		14. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	14.4. Key Length Considerations . . . . . . . . . . . . . . . 20		14.1. Zone Enumeration Attacks . . . . . . . . . . . . . . . . 24
	14.5. Transitioning to a New NSEC5 Algorithm . . . . . . . . . 20		14.2. Hash Collisions . . . . . . . . . . . . . . . . . . . . 24
	15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		14.3. Compromise of the Private NSEC5 Key . . . . . . . . . . 24
	16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21		14.4. Key Length Considerations . . . . . . . . . . . . . . . 25
	17. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		14.5. Transitioning to a New NSEC5 Algorithm . . . . . . . . . 25
	17.1. Normative References . . . . . . . . . . . . . . . . . . 21		15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	17.2. Informative References . . . . . . . . . . . . . . . . . 22		16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
	Appendix A. Full Domain Hash Algorithm . . . . . . . . . . . . . 23		17. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
	A.1. FDH signature . . . . . . . . . . . . . . . . . . . . . . 23		17.1. Normative References . . . . . . . . . . . . . . . . . . 26
	A.2. FDH verification . . . . . . . . . . . . . . . . . . . . 24		17.2. Informative References . . . . . . . . . . . . . . . . . 27
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25		Appendix A. Full Domain Hash Algorithm . . . . . . . . . . . . . 28
	Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 25		A.1. FDH signature . . . . . . . . . . . . . . . . . . . . . . 28
			A.2. FDH verification . . . . . . . . . . . . . . . . . . . . 29
			Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 29
			Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 30
	1. Introduction		1. Introduction
	1.1. Rationale		1.1. Rationale
	The DNS Security Extensions (DNSSEC) provides data integrity		The DNS Security Extensions (DNSSEC) provides data integrity
	protection using public-key cryptography, while not requiring that		protection using public-key cryptography, while not requiring that
	authoritative servers compute signatures on-the-fly. The content of		authoritative servers compute signatures on-the-fly. The content of
	the zone is usually pre-computed and served as is. The evident		the zone is usually pre-computed and served as is. The evident
	advantages of this approach are reduced performance requirements per		advantages of this approach are reduced performance requirements per
	skipping to change at page 3, line 46 ¶		skipping to change at page 3, line 49 ¶
	With DNSSEC, each resource record (RR) set in the zone is signed.		With DNSSEC, each resource record (RR) set in the zone is signed.
	The signature is retained as an RRSIG RR directly in the zone. This		The signature is retained as an RRSIG RR directly in the zone. This
	enables response authentication for data existing in the zone. To		enables response authentication for data existing in the zone. To
	ensure integrity of denying answers, an NSEC chain of all existing		ensure integrity of denying answers, an NSEC chain of all existing
	domain names in the zone is constructed. The chain is made of RRs,		domain names in the zone is constructed. The chain is made of RRs,
	where each RR represents two consecutive domain names in canonical		where each RR represents two consecutive domain names in canonical
	order present in the zone. The NSEC RRs are signed the same way as		order present in the zone. The NSEC RRs are signed the same way as
	any other RRs in the zone, and each NSEC can be used to prove that a		any other RRs in the zone, and each NSEC can be used to prove that a
	given name does not existing in a part of the domain name space.		given name does not existing in a part of the domain name space.
	As side-effect, however, the NSEC chain existence allows for the		As side-effect, however, the NSEC chain allows for enumeration of the
	enumeration of the zone's contents by querying for names immediately		zone's contents by sequentially querying for the names immediately
	individual RRs in the chain; N queries suffice to enumerate a zone		following those in the most-recently retrieved NSEC record; N queries
	containing N names. As such, the NSEC3 hashed denial of existence		suffice to enumerate a zone containing N names. As such, the NSEC3
	was introduced to prevent zone enumeration. In NSEC3, the original		hashed denial of existence was introduced to prevent zone
	domain names in the NSEC chain are replaced by their cryptographic		enumeration. In NSEC3, the original domain names in the NSEC chain
	hashes. While NSEC3 makes zone enumeration more difficult, offline		are replaced by their cryptographic hashes. While NSEC3 makes zone
	dictionary attacks are still possible and have been demonstrated;		enumeration more difficult, offline dictionary attacks are still
	this is because hashes may be computed offline and the space of		possible and have been demonstrated; this is because hashes may be
	possible domain names is restricted [nsec3walker][nsec3gpu].		computed offline and the space of possible domain names is restricted
			[nsec3walker][nsec3gpu].
	Zone enumeration can be prevented with NSEC3 if having the		Zone enumeration can be prevented with NSEC3 if having the
	authoritative server compute NSEC3 RRs on-the-fly, in response to		authoritative server compute NSEC3 RRs on-the-fly, in response to
	queries with denying responses. Usually, this is done with Minimally		queries with denying responses. Usually, this is done with Minimally
	Covering NSEC Records or NSEC3 White Lies [RFC7129]. One of the most		Covering NSEC Records or NSEC3 White Lies [RFC7129]. One of the most
	significant disadvantage of this approach is a required presence of		significant disadvantage of this approach is a required presence of
	the private key on all authoritative servers for the zone. This is		the private key on all authoritative servers for the zone. This is
	often undesirable, as the holder of the private key can tamper with		often undesirable, as the holder of the private key can tamper with
	the zone content, and having private keys on many network-facing		the zone content, and having private keys on many network-facing
	servers increases the risk that keys can be compromised.		servers increases the risk that keys can be compromised.
	skipping to change at page 4, line 36 ¶		skipping to change at page 4, line 40 ¶
	compute hash values.		compute hash values.
	Importantly, the NSEC5KEY key cannot be used to modify the contents		Importantly, the NSEC5KEY key cannot be used to modify the contents
	of the zone. Thus, any compromise of the private NSEC5 key does not		of the zone. Thus, any compromise of the private NSEC5 key does not
	lead to a compromise of zone contents; all that is lost is privacy		lead to a compromise of zone contents; all that is lost is privacy
	against zone enumeration, effectively downgrading the security of		against zone enumeration, effectively downgrading the security of
	NSEC5 to that of NSEC3. NSEC5 comes with a cryptographic proof of		NSEC5 to that of NSEC3. NSEC5 comes with a cryptographic proof of
	security, available in [nsec5].		security, available in [nsec5].
	The NSEC5 is not intended to replace NSEC or NSEC3. It is designed		The NSEC5 is not intended to replace NSEC or NSEC3. It is designed
	as an alternative mechanisms for authenticated denial of existence.		as an alternative mechanism for authenticated denial of existence.
	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
	skipping to change at page 6, line 29 ¶		skipping to change at page 6, line 35 ¶
	NSEC5PROOF RR containing the NSEC5 proof it computed on the fly.		NSEC5PROOF RR containing the NSEC5 proof it computed on the fly.
	To validate the response, the client first uses the public NSEC5 key		To validate the response, the client first uses the public NSEC5 key
	(stored in the zone as an NSEC5KEY RR) to verify that the NSEC5 proof		(stored in the zone as an NSEC5KEY RR) to verify that the NSEC5 proof
	corresponds with the domain name to be disproved. Then, the client		corresponds with the domain name to be disproved. Then, the client
	computes the NSEC5 hash from the NSEC5 proof and checks if the NSEC5		computes the NSEC5 hash from the NSEC5 proof and checks if the NSEC5
	RR content and it's signature are valid.		RR content and it's signature are valid.
	4. NSEC5 Algorithms		4. NSEC5 Algorithms
	The algorithms used for NSEC5 authenticated denial are independent on		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 is computed and validated.		how the NSEC5 proof and the NSEC5 hash is computed and validated.
	The input for the NSEC5 proof computation is an RR owner name in the		The input for the NSEC5 proof computation is an RR owner name in the
	canonical form in the wire format and an NSEC5 private key; the		canonical form in the wire format and an NSEC5 private key; the
	output is an octet string.		output is an octet string.
	The input for the NSEC5 hash computation is the corresponding NSEC5		The input for the NSEC5 hash computation is the corresponding NSEC5
	proof; the output is an octet string.		proof; the output is an octet string.
	skipping to change at page 19, line 7 ¶		skipping to change at page 19, line 18 ¶
	With FDH-SHA256-SHA256 defined in this document, the SHA-256 hash		With FDH-SHA256-SHA256 defined in this document, the SHA-256 hash
	function is used to construct NSEC5 hash values. SHA-256 produces a		function is used to construct NSEC5 hash values. SHA-256 produces a
	hash of 256 bits, which can be encoded in 52 characters in Base32hex		hash of 256 bits, which can be encoded in 52 characters in Base32hex
	without padding. The encoded string is prepended to the name of the		without padding. The encoded string is prepended to the name of the
	zone as a single label, which includes the length field of a single		zone as a single label, which includes the length field of a single
	octet. The maximal length of the zone name is therefore 202 octets		octet. The maximal length of the zone name is therefore 202 octets
	(255 - 53).		(255 - 53).
	13. Performance Considerations		13. Performance Considerations
	TODO: Not finished. Following information will be covered:		This section compares NSEC, NSEC3, and NSEC5 with regards to the size
			of denial-of-existence responses and performance impact on the DNS
			components.
	o Size of the answers		13.1. Performance of Cryptographic Operations
	o NSEC5 FDH-SHA256-SHA256 vs NSEC3 SHA1		Additional performance costs depend on the costs of cryptographic
			operations to a great extent. The following results were retrieved
			with OpenSSL 1.0.1k, running an ordinary laptop on a single-core of a
			CPU manufactured in 2011. The parameters of cryptographic operations
			were chosen to reflect the parameters used in the real-world
			application of DNSSEC.
	o NSEC5 closest encloser name in NSEC5PROOF owner name vs NSEC5 SHA1		Comparison of NSEC3 and NSEC5 hashing performance:
	hashing
	o Total number of crypto operations on server/client side		o NSEC3 uses multiple iterations of the SHA-1 function with an
			arbitrary salt. The input of the first iteration is the domain
			name in wire format together with binary salt; the input of the
			subsequent iterations is the binary digest and the salt. We can
			assume that the input size will be smaller than 32 octets for most
			executions.
			The measured implementation gives a stable performance for small
			input blocks up to 32 octets. About 3e6 hashes per second can be
			computed given these parameters.
			The number of additional iterations in NSEC3 parameters will
			probably vary between 0 and 20 in reality. Therefore we can
			expect the NSEC3 hash computation performance to be between 2e5
			and 3e6 hashes per second.
			o The NSEC5 hash is computed in two steps: NSEC5 proof computation
			followed by hashing of the result. The NSEC5 proof is basically
			an RSA signature and the performance will therefore vary for
			signing and verification and also for different key sizes. We can
			expect that the final hashing will have insignificant impact on
			the overall hashing performance.
			The measurement of NSEC5 proof computation and verification
			resulted into the following numbers: 3e3 sign/s and 4e4 verify/s
			for 1024-bit key; 4e2 sign/s and 1e4 verify/s for 2048-bit key;
			and 5e1 sign/s and 3e3 verify/s for 4096-bit key.
			The final SHA-256 hashing is about two orders of magnitude faster
			given the input block size matching the NSEC5 proof result size.
			Picking a moderate key size of 2048-bits, the NSEC5 hash
			computation performance will be in the order of 10^2 issued hashes
			per second and 10^4 validated hashes per second.
			According to the results, the NSEC5 hashing is about three orders of
			magnitude slower than NSEC3 hashing and the NSEC5 hash verification
			is about one order of magnitude slower than NSEC3 hash verification.
			Comparison of signing and verification performance of different
			DNSSEC signing algorithms:
			+-----------------+---------+-----------+-------------+-------------+
			| Algorithm | Key | Signature | Performance | Performance |
			| | size | size | (sign/s) | (verify/s) |
			| | (bits) | (octets) | | |
			+-----------------+---------+-----------+-------------+-------------+
			| RSASHA256 | 1024 | 128 | 2000 | 40000 |
			| RSASHA256 | 2048 | 256 | 400 | 10000 |
			| RSASHA256 | 4096 | 512 | 50 | 3000 |
			| ECDSAP256SHA256 | 256 | 64 | 5000 | 1000 |
			| ECDSAP384SHA384 | 384 | 96 | 3000 | 600 |
			+-----------------+---------+-----------+-------------+-------------+
			The retrieved values are important primarily for the purpose of
			evaluating performance of response validation. The signing
			performance is not that important because the zone is usually signed
			offline.
			13.2. Authoritative Server Startup
			This section compares additional server startup cost based on the
			used authenticated denial mechanism.
			NSEC There are no special requirements on processing of a NSEC-
			signed zone during an authoritative server startup. The server
			handles the NSEC RRs the same way as any other records in the
			zone.
			NSEC3 The authoritative server can precompute NSEC3 hashes for all
			domain names in the NSEC3-signed zone on startup. With respect to
			query answering, this can speed up inclusion of NSEC3 RRs for
			existing domain names (i.e., Closest provable encloser and QNAME
			for No Data response).
			NSEC5 Very similar considerations apply for NSEC3 and NSEC5. There
			is a strong motivation to precompute the NSEC5 proofs because they
			are costly to compute. A possible solution to reduce the startup
			time is to store the precomputed NSEC5 proofs and NSEC5 hashes in
			a persistent storage.
			The impact of NSEC3 and NSEC5 on the authoritative server startup
			performance is greatly implementation specific. The server software
			vendor has to seek balance between answering performance, startup
			slowdown, and additional storage cost.
			13.3. NSEC5 Answer Generating and Processing
			An authenticated denial proof is required for No Data, Name Error,
			Wildcard Match, and Wildcard No Data answer. The number of required
			records depends on used authenticated denial mechanism. Their size,
			generation cost, and validation cost depend on various zone and
			signing parameters.
			In the worst case, the following additional records authenticating
			the denial will be included into the response:
			o Up to two NSEC records and their associated RRSIG records.
			o Up to three NSEC3 records and their associated RRSIG records.
			o Up to two NSEC5 records and their associated NSEC5PROOF and RRSIG
			records.
			The following table compares the size of NSEC, NSEC3, and NSEC5
			records. We assume the SHA-1 hash algorithm for NSEC3 and the FDH-
			SHA256-SHA256 algorithm for NSEC5.
			+-------+------------+---------------+-----------------------+
			| | Fixed part | Common part | RR type-specific part |
			+-------+------------+---------------+-----------------------+
			| NSEC | 10 octets | Type Bit Maps | Owner Name, Next Name |
			| NSEC3 | 64 octets | Type Bit Maps | Salt |
			| NSEC5 | 101 octets | Type Bit Maps | - |
			+-------+------------+---------------+-----------------------+
			The size covers complete RR representation in wire format:
			o The Fixed part includes length of all fixed-size fields in the RR;
			and also a size of generally variable-sized fields whose length
			can determined from the used parameters (e.g., the NSEC3 owner
			name consists from one label encoding the hash and a compression
			pointer to zone apex).
			o The Common part includes the only field shared among the RR types.
			o The RR type-specific part contains unique fields present in the RR
			types whose length will vary. Note that the Owner Name can be
			compressed, but Next Name must not. Also note that the Salt in
			NSEC3 will have constant size for all NSEC3 records in the chain.
			The size of RRSIG RR is a sum of length of possibly compressed RR
			owner name, 28 octets for fixed-size fields, the length of
			uncompressed signer name, and the length of the signature.
			The size of NSEC5PROOF RR is a sum of length of possibly compressed
			RR owner name, 2 octets for fixed-size fields, and the length of the
			proof.
			The following list summarizes the increase of the DNS response size
			for authenticated denial worst-case scenario. As a significant part
			of the increase is caused by the used DNSSEC signing algorithm, the
			summary includes two variants: RSA stands for the RSASHA256 algorithm
			with 2048-bit key and ECDSA stands for the ECDSAP256SHA256 algorithm.
			For NSEC5, FDH-SHA256-SHA256 with 2048-bit key is used.
			o NSEC:
			* 4 x compressed domain name
			* 4 x uncompressed domain name
			* 2 x type bit bitmap
			* 588 octets (RSA) or 204 octets (ECDSA)
			o NSEC3:
			* 3 x compressed domain name
			* 3 x uncompressed domain name
			* 3 x salt
			* 3 x type bit map
			* 969 octets (RSA) or 393 octets (ECDSA)
			o NSEC5:
			* 4 x compressed domain name
			* 2 x uncompressed domain name
			* 2 x type bit map
			* 1286 octets (RSA) or 902 octets (ECDSA)
			The following list summarizes additional cryptographic operations
			performed by the authoritative server for authenticated denial worst-
			case scenario:
			o NSEC:
			* No cryptographic operations required.
			o NSEC3:
			* NSEC3 hash for Closest provable encloser (possibly precomputed)
			* NSEC3 hash for Next closer name
			* NSEC3 hash for wildcard at the closest encloser
			o NSEC5:
			* NSEC5 proof and hash for Closest provable encloser (possibly
			precomputed)
			* NSEC5 proof and hash for Next closer name
			As anticipated, NSEC is the most efficient authenticated denial
			mechanism as for response size and performance cost. The bottleneck
			of NSEC5 is the NSEC5 proof computation. If the proofs are
			precomputed for domain names in the zone, the server has to compute
			just one NSEC5 proof per answer. But it will still be more expensive
			than NSEC3 and the same applies for the response size.
			As for the response processing, the validation cost reflects from the
			records present in the response. Again, the NSEC validation seems to
			be the most inexpensive. However the difference between RSA and
			ECDSA verification performance is huge and for some parameters, NSEC3
			is faster to validate than NSEC5 and vice versa.
	14. Security Considerations		14. Security Considerations
	14.1. Zone Enumeration Attacks		14.1. Zone Enumeration Attacks
	NSEC5 is robust to zone enumeration via offline dictionary attacks by		NSEC5 is robust to zone enumeration via offline dictionary attacks by
	any attacker that does not know the NSEC5 private key. Without the		any attacker that does not know the NSEC5 private key. Without the
	private NSEC5 key, that attacker cannot compute the NSEC5 proof that		private NSEC5 key, that attacker cannot compute the NSEC5 proof that
	corresponds to a given name; the only way it can learn the NSEC5		corresponds to a given name; the only way it can learn the NSEC5
	proof value for a given name is by sending a queries for that name to		proof value for a given name is by sending a queries for that name to
	skipping to change at page 25, line 4 ¶		skipping to change at page 29, line 44 ¶
	"valid signature" or "invalid signature"		"valid signature" or "invalid signature"
	Steps:		Steps:
	1. s = OS2IP(S)		1. s = OS2IP(S)
	2. m = RSAVP1((n, e), s)		2. m = RSAVP1((n, e), s)
	3. EM = I2OSP(m, k - 1)		3. EM = I2OSP(m, k - 1)
	4. EM' = MGF1(M, k - 1)		4. EM' = MGF1(M, k - 1)
	5. If EM and EM' are the same, output "valid signature"; else output		5. If EM and EM' are the same, output "valid signature"; else output
	"invalid signature".		"invalid signature".
	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,
	clarify inputs and outputs for NSEC5 proof and NSEC5 hash		clarify inputs and outputs for NSEC5 proof and NSEC5 hash
	computation		computation
			01 - added Performance Considerations section
	Appendix C. Open Issues		Appendix C. Open Issues
	Note to RFC Editor: please remove this appendix before publication as		Note to RFC Editor: please remove this appendix before publication as
	an RFC.		an RFC.
	1. Consider alternative way to signalize NSEC5 support. The NSEC5		1. Consider alternative way to signalize NSEC5 support. The NSEC5
	could use only one DNSSEC algorithm identifier, and the actual		could use only one DNSSEC algorithm identifier, and the actual
	algorithm to be used for signing can be the first byte in DNSKEY		algorithm to be used for signing can be the first octet in DNSKEY
	public key field and RRSIG signature field. Similar approach is		public key field and RRSIG signature field. Similar approach is
	used by PRIVATEDNS and PRIVATEOID defined in [RFC4034].		used by PRIVATEDNS and PRIVATEOID defined in [RFC4034].
	2. How to add new NSEC5 hashing algorithm. We will need to add new		2. How to add new NSEC5 hashing algorithm. We will need to add new
	DNSSEC algorithm identifiers again.		DNSSEC algorithm identifiers again.
	3. NSEC and NSEC3 define optional steps for hash collisions		3. NSEC and NSEC3 define optional steps for hash collisions
	detection. We don't have a way to avoid them if they really		detection. We don't have a way to avoid them if they really
	appear (unlikely). We would have to drop the signing key and		appear (unlikely). We would have to drop the signing key and
	generate a new one. Which cannot be done instantly.		generate a new one. Which cannot be done instantly.
	4. Write Special Considerations section.		4. Write Special Considerations section.
	5. Write Performance Considerations section.		5. Contributor list has to be completed.
	6. Contributor list has to be completed.
	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
End of changes. 23 change blocks.
	49 lines changed or deleted		270 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/