< draft-ietf-dnsext-nsec3-12.txt		draft-ietf-dnsext-nsec3-13.txt >
	Network Working Group B. Laurie		Network Working Group B. Laurie
	Internet-Draft G. Sisson		Internet-Draft G. Sisson
	Intended status: Standards Track R. Arends		Intended status: Standards Track R. Arends
	Expires: January 2, 2008 Nominet		Expires: June 13, 2008 Nominet
	D. Blacka		D. Blacka
	VeriSign, Inc.		VeriSign, Inc.
	July 2007		December 11, 2007
	DNSSEC Hashed Authenticated Denial of Existence		DNSSEC Hashed Authenticated Denial of Existence
	draft-ietf-dnsext-nsec3-12		draft-ietf-dnsext-nsec3-13
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 2, 2008.		This Internet-Draft will expire on June 13, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	The Domain Name System Security Extensions (DNSSEC) introduced the		The Domain Name System Security Extensions (DNSSEC) introduced the
	NSEC resource record (RR) for authenticated denial of existence.		NSEC resource record (RR) for authenticated denial of existence.
	This document introduces an alternative resource record, NSEC3, which		This document introduces an alternative resource record, NSEC3, which
	skipping to change at page 3, line 25 ¶		skipping to change at page 3, line 25 ¶
	9. Resolver Considerations . . . . . . . . . . . . . . . . . . . 25		9. Resolver Considerations . . . . . . . . . . . . . . . . . . . 25
	9.1. NSEC3 Resource Record Caching . . . . . . . . . . . . . . 25		9.1. NSEC3 Resource Record Caching . . . . . . . . . . . . . . 25
	9.2. Use of the AD Bit . . . . . . . . . . . . . . . . . . . . 25		9.2. Use of the AD Bit . . . . . . . . . . . . . . . . . . . . 25
	10. Special Considerations . . . . . . . . . . . . . . . . . . . . 26		10. Special Considerations . . . . . . . . . . . . . . . . . . . . 26
	10.1. Domain Name Length Restrictions . . . . . . . . . . . . . 26		10.1. Domain Name Length Restrictions . . . . . . . . . . . . . 26
	10.2. DNAME at the Zone Apex . . . . . . . . . . . . . . . . . . 26		10.2. DNAME at the Zone Apex . . . . . . . . . . . . . . . . . . 26
	10.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 26		10.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 26
	10.4. Transitioning a Signed Zone from NSEC to NSEC3 . . . . . . 27		10.4. Transitioning a Signed Zone from NSEC to NSEC3 . . . . . . 27
	10.5. Transitioning a Signed Zone From NSEC3 to NSEC . . . . . . 28		10.5. Transitioning a Signed Zone From NSEC3 to NSEC . . . . . . 28
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 29		12. Security Considerations . . . . . . . . . . . . . . . . . . . 30
	12.1. Hashing Considerations . . . . . . . . . . . . . . . . . . 30		12.1. Hashing Considerations . . . . . . . . . . . . . . . . . . 30
	12.1.1. Dictionary Attacks . . . . . . . . . . . . . . . . . . 30		12.1.1. Dictionary Attacks . . . . . . . . . . . . . . . . . . 30
	12.1.2. Collisions . . . . . . . . . . . . . . . . . . . . . . 30		12.1.2. Collisions . . . . . . . . . . . . . . . . . . . . . . 30
	12.1.3. Transitioning to a New Hash Algorithm . . . . . . . . 30		12.1.3. Transitioning to a New Hash Algorithm . . . . . . . . 30
	12.1.4. Using High Iteration Values . . . . . . . . . . . . . 31		12.1.4. Using High Iteration Values . . . . . . . . . . . . . 31
	12.2. Opt-Out Considerations . . . . . . . . . . . . . . . . . . 32		12.2. Opt-Out Considerations . . . . . . . . . . . . . . . . . . 31
	12.3. Other Considerations . . . . . . . . . . . . . . . . . . . 32		12.3. Other Considerations . . . . . . . . . . . . . . . . . . . 32
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 33		13.1. Normative References . . . . . . . . . . . . . . . . . . . 32
	13.2. Informative References . . . . . . . . . . . . . . . . . . 34		13.2. Informative References . . . . . . . . . . . . . . . . . . 33
	Appendix A. Example Zone . . . . . . . . . . . . . . . . . . . . 34		Appendix A. Example Zone . . . . . . . . . . . . . . . . . . . . 34
	Appendix B. Example Responses . . . . . . . . . . . . . . . . . . 39		Appendix B. Example Responses . . . . . . . . . . . . . . . . . . 39
	B.1. Name Error . . . . . . . . . . . . . . . . . . . . . . . . 39		B.1. Name Error . . . . . . . . . . . . . . . . . . . . . . . . 39
	B.2. No Data Error . . . . . . . . . . . . . . . . . . . . . . 41		B.2. No Data Error . . . . . . . . . . . . . . . . . . . . . . 41
	B.2.1. No Data Error, Empty Non-Terminal . . . . . . . . . . 42		B.2.1. No Data Error, Empty Non-Terminal . . . . . . . . . . 41
	B.3. Referral to an Opt-Out Unsigned Zone . . . . . . . . . . . 43		B.3. Referral to an Opt-Out Unsigned Zone . . . . . . . . . . . 42
	B.4. Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 45		B.4. Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 44
	B.5. Wildcard No Data Error . . . . . . . . . . . . . . . . . . 47		B.5. Wildcard No Data Error . . . . . . . . . . . . . . . . . . 46
	B.6. DS Child Zone No Data Error . . . . . . . . . . . . . . . 48		B.6. DS Child Zone No Data Error . . . . . . . . . . . . . . . 47
	Appendix C. Special Considerations . . . . . . . . . . . . . . . 49		Appendix C. Special Considerations . . . . . . . . . . . . . . . 48
	C.1. Salting . . . . . . . . . . . . . . . . . . . . . . . . . 49		C.1. Salting . . . . . . . . . . . . . . . . . . . . . . . . . 48
	C.2. Hash Collision . . . . . . . . . . . . . . . . . . . . . . 50		C.2. Hash Collision . . . . . . . . . . . . . . . . . . . . . . 49
	C.2.1. Avoiding Hash Collisions During Generation . . . . . . 50		C.2.1. Avoiding Hash Collisions During Generation . . . . . . 49
	C.2.2. Second Preimage Requirement Analysis . . . . . . . . . 51		C.2.2. Second Preimage Requirement Analysis . . . . . . . . . 50
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
	Intellectual Property and Copyright Statements . . . . . . . . . . 53		Intellectual Property and Copyright Statements . . . . . . . . . . 52
	1. Introduction		1. Introduction
	1.1. Rationale		1.1. Rationale
	The DNS Security Extensions included the NSEC RR to provide		The DNS Security Extensions included the NSEC RR to provide
	authenticated denial of existence. Though the NSEC RR meets the		authenticated denial of existence. Though the NSEC RR meets the
	requirements for authenticated denial of existence, it introduces a		requirements for authenticated denial of existence, it introduces a
	side-effect in that the contents of a zone can be enumerated. This		side-effect in that the contents of a zone can be enumerated. This
	property introduces undesired policy issues.		property introduces undesired policy issues.
	The enumeration is enabled by the set of NSEC records that exists in		The enumeration is enabled by the set of NSEC records that exists
	a side signed zone. An NSEC record lists two names that are ordered		inside a signed zone. An NSEC record lists two names that are
	canonically, in order to show that nothing exists between the two		ordered canonically, in order to show that nothing exists between the
	names. The complete set of NSEC records lists all the names in a		two names. The complete set of NSEC records lists all the names in a
	zone. It is trivial to enumerate the content of a zone by querying		zone. It is trivial to enumerate the content of a zone by querying
	for names that do not exist.		for names that do not exist.
	An enumerated zone can be used, for example, as a source of probable		An enumerated zone can be used, for example, as a source of probable
	e-mail addresses for spam, or as a key for multiple WHOIS queries to		e-mail addresses for spam, or as a key for multiple WHOIS queries to
	reveal registrant data which many registries may have legal		reveal registrant data which many registries may have legal
	obligations to protect. Many registries therefore prohibit copying		obligations to protect. Many registries therefore prohibit copying
	of their zone data; however, the use of NSEC RRs renders these		of their zone data; however, the use of NSEC RRs renders these
	policies unenforceable.		policies unenforceable.
	skipping to change at page 28, line 29 ¶		skipping to change at page 28, line 29 ¶
	the NSEC RRs for negative and wildcard responses.		the NSEC RRs for negative and wildcard responses.
	3. Remove the NSEC3 RRs either incrementally or all at once.		3. Remove the NSEC3 RRs either incrementally or all at once.
	4. Transition all of the DNSKEYs to DNSSEC algorithm identifiers.		4. Transition all of the DNSKEYs to DNSSEC algorithm identifiers.
	After this transition is complete, all NSEC3-unaware clients will		After this transition is complete, all NSEC3-unaware clients will
	treat the zone as secure.		treat the zone as secure.
	11. IANA Considerations		11. IANA Considerations
			Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm
			parameter, this document does not define a particular mechanism for
			safely transitioning from one NSEC3 hash algorithm to another. When
			specifying a new hash algorithm for use with NSEC3, a transition
			mechanism MUST also be defined.
	This document updates the IANA registry "DOMAIN NAME SYSTEM		This document updates the IANA registry "DOMAIN NAME SYSTEM
	PARAMETERS" [http://www.iana.org/assignments/dns-parameters] in sub-		PARAMETERS" [http://www.iana.org/assignments/dns-parameters] in sub-
	registry "TYPES", by defining two new types. Section 3 defines the		registry "TYPES", by defining two new types. Section 3 defines the
	NSEC3 RR type NN, (value 50 suggested). Section 4 defines the		NSEC3 RR type NN, (value 50 suggested). Section 4 defines the
	NSEC3PARAM RR type MM (value 51 suggested).		NSEC3PARAM RR type MM (value 51 suggested).
	This document updates the IANA registry "DNS SECURITY ALGORITHM		This document updates the IANA registry "DNS SECURITY ALGORITHM
	NUMBERS - per [RFC4035]"		NUMBERS - per [RFC4035]"
	http://www.iana.org/assignments/dns-sec-alg-numbers]. Section 2		http://www.iana.org/assignments/dns-sec-alg-numbers]. Section 2
	defines the aliases DSA-NSEC3-SHA1 (XX) and RSASHA1-NSEC3-SHA1 (YY)		defines the aliases DSA-NSEC3-SHA1 (XX) and RSASHA1-NSEC3-SHA1 (YY)
	skipping to change at page 30, line 41 ¶		skipping to change at page 30, line 44 ¶
	Hash collisions between QNAME and the owner name of an NSEC3 RR may		Hash collisions between QNAME and the owner name of an NSEC3 RR may
	occur. When they do, it will be impossible to prove the non-		occur. When they do, it will be impossible to prove the non-
	existence of the colliding QNAME. However, with SHA-1, this is		existence of the colliding QNAME. However, with SHA-1, this is
	highly unlikely (on the order of 1 in 2^160). Note that DNSSEC		highly unlikely (on the order of 1 in 2^160). Note that DNSSEC
	already relies on the presumption that a cryptographic hash function		already relies on the presumption that a cryptographic hash function
	is second pre-image resistant, since these hash functions are used		is second pre-image resistant, since these hash functions are used
	for generating and validating signatures and DS RRs.		for generating and validating signatures and DS RRs.
	12.1.3. Transitioning to a New Hash Algorithm		12.1.3. Transitioning to a New Hash Algorithm
	Since validators are instructed to ignore NSEC3 RRs with unknown hash		Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm
	algorithms, simply using a new or unknown hash algorithm directly		parameter, this document does not define a particular mechanism for
	will lead to validation failures with clients that understand NSEC3		safely transitioning from one NSEC3 hash algorithm to another. When
	but do not understand the hash algorithm.		specifying a new hash algorithm for use with NSEC3, a transition
			mechanism MUST also be defined. It is possible that the only
	When transitioning to a new hash algorithm, care must be taken to		practical and palatable transition mechanisms may require an
	prevent client validation failures during the process. This is done		intermediate transition to an insecure state, or to a state that uses
	using a similar procedure to transitioning from NSEC to NSEC3		NSEC records instead of NSEC3.
	(Section 10.4)
	The basic procedure is as follows:
	1. Transition all DNSKEYs to DNSKEYs using the algorithm aliases
	allocated for the new NSEC3 hash algorithm. The actual method
	for safely and securely changing the DNSKEY RRSet of the zone is
	outside the scope of this specification. However, the end result
	MUST be that all DS RRs in the parent use the specified algorithm
	aliases.
	After this transition is complete, all clients unaware of the new
	hash algorithm will treat the zone as insecure. At this point,
	the authoritative server still returns negative and wildcard
	responses that contain NSEC3 RRs with the known hash function.
	2. Add signed NSEC3 RRs with the new hash algorithm to the zone,
	either incrementally or all at once. If adding incrementally,
	then the last RRSet added MUST be the NSEC3PARAM RRSet containing
	the new hash algorithm.
	3. Upon the addition of the NSEC3PARAM RR containing the new hash
	algorithm, and after the removal of the NSEC3PARAM RR containing
	the old hash algorithm, the server switches to serving negative
	and wildcard responses with NSEC3 RRs containing the new hash
	algorithm.
	4. Remove the NSEC3 RRs containing the old hash algorithm either
	incrementally or all at once.
	12.1.4. Using High Iteration Values		12.1.4. Using High Iteration Values
	Since validators should treat responses containing NSEC3 RRs with		Since validators should treat responses containing NSEC3 RRs with
	high iteration values as insecure, presence of just one signed NSEC3		high iteration values as insecure, presence of just one signed NSEC3
	RR with a high iteration value in a zone provides attackers with a		RR with a high iteration value in a zone provides attackers with a
	possible downgrade attack.		possible downgrade attack.
	The attack is simply to remove any existing NSEC3 RRs from a		The attack is simply to remove any existing NSEC3 RRs from a
	response, and replace or add a single (or multiple) NSEC3 RR that		response, and replace or add a single (or multiple) NSEC3 RR that
	skipping to change at page 51, line 38 ¶		skipping to change at page 50, line 38 ¶
	Nominet		Nominet
	17 Perryn Road		17 Perryn Road
	London W3 7LR		London W3 7LR
	England		England
	Phone: +44 20 8735 0686		Phone: +44 20 8735 0686
	Email: ben@links.org		Email: ben@links.org
	Geoffrey Sisson		Geoffrey Sisson
	Nominet		Nominet
	Sandford Gate		Minerva House
	Sandy Lane West		Edmund Halley Road
	Oxford OX4 6LB		Oxford Science Park
			Oxford OX4 4DQ
	UNITED KINGDOM		UNITED KINGDOM
	Phone: +44 1865 332211		Phone: +44 1865 332211
	Email: geoff@nominet.org.uk		Email: geoff@nominet.org.uk
	Roy Arends		Roy Arends
	Nominet		Nominet
	Sandford Gate		Minerva House
	Sandy Lane West		Edmund Halley Road
	Oxford OX4 6LB		Oxford Science Park
			Oxford OX4 4DQ
	UNITED KINGDOM		UNITED KINGDOM
	Phone: +44 1865 332211		Phone: +44 1865 332211
	Email: roy@nominet.org.uk		Email: roy@nominet.org.uk
	David Blacka		David Blacka
	VeriSign, Inc.		VeriSign, Inc.
	21355 Ridgetop Circle		21355 Ridgetop Circle
	Dulles, VA 20166		Dulles, VA 20166
	US		US
End of changes. 13 change blocks.
	68 lines changed or deleted		47 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/