< draft-ietf-dnsext-dnssec-online-signing-01.txt		draft-ietf-dnsext-dnssec-online-signing-02.txt >
	Network Working Group S. Weiler		Network Working Group S. Weiler
	Internet-Draft SPARTA, Inc		Internet-Draft SPARTA, Inc
	Updates: 4034, 4035 (if approved) J. Ihren		Updates: 4034, 4035 (if approved) J. Ihren
	Expires: July 9, 2006 Autonomica AB		Expires: July 24, 2006 Autonomica AB
	January 5, 2006		January 20, 2006
	Minimally Covering NSEC Records and DNSSEC On-line Signing		Minimally Covering NSEC Records and DNSSEC On-line Signing
	draft-ietf-dnsext-dnssec-online-signing-01		draft-ietf-dnsext-dnssec-online-signing-02
	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 35 ¶		skipping to change at page 1, line 35 ¶
	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 July 9, 2006.		This Internet-Draft will expire on July 24, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document describes how to construct DNSSEC NSEC resource records		This document describes how to construct DNSSEC NSEC resource records
	that cover a smaller range of names than called for by RFC4034. By		that cover a smaller range of names than called for by RFC4034. By
	generating and signing these records on demand, authoritative name		generating and signing these records on demand, authoritative name
	servers can effectively stop the disclosure of zone contents		servers can effectively stop the disclosure of zone contents
	otherwise made possible by walking the chain of NSEC records in a		otherwise made possible by walking the chain of NSEC records in a
	signed zone.		signed zone.
			Changes from ietf-01 to ietf-02
			Clarified that a generated NSEC RR's type bitmap MUST have the RRSIG
			and NSEC bits set, to be consistent with DNSSECbis -- previous text
			said SHOULD.
			Made the applicability statement a little less oppressive.
	Changes from ietf-00 to ietf-01		Changes from ietf-00 to ietf-01
	Added an applicability statement, making reference to ongoing work on		Added an applicability statement, making reference to ongoing work on
	NSEC3.		NSEC3.
	Added the phrase "epsilon functions", which has been commonly used to		Added the phrase "epsilon functions", which has been commonly used to
	describe the technique and already appeared in the header of each		describe the technique and already appeared in the header of each
	page, in place of "increment and decrement functions". Also added an		page, in place of "increment and decrement functions". Also added an
	explanatory sentence.		explanatory sentence.
	skipping to change at page 3, line 14 ¶		skipping to change at page 3, line 14 ¶
	Table of Contents		Table of Contents
	1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4		1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4
	2. Applicability of This Technique . . . . . . . . . . . . . . . 4		2. Applicability of This Technique . . . . . . . . . . . . . . . 4
	3. Minimally Covering NSEC Records . . . . . . . . . . . . . . . 5		3. Minimally Covering NSEC Records . . . . . . . . . . . . . . . 5
	4. Better Epsilon Functions . . . . . . . . . . . . . . . . . . . 6		4. Better Epsilon Functions . . . . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	7. Normative References . . . . . . . . . . . . . . . . . . . . . 8		7. Normative References . . . . . . . . . . . . . . . . . . . . . 8
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 9		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	Intellectual Property and Copyright Statements . . . . . . . . . . 11		Intellectual Property and Copyright Statements . . . . . . . . . . 11
	1. Introduction and Terminology		1. Introduction and Terminology
	With DNSSEC [1], an NSEC record lists the next instantiated name in		With DNSSEC [1], an NSEC record lists the next instantiated name in
	its zone, proving that no names exist in the "span" between the		its zone, proving that no names exist in the "span" between the
	NSEC's owner name and the name in the "next name" field. In this		NSEC's owner name and the name in the "next name" field. In this
	document, an NSEC record is said to "cover" the names between its		document, an NSEC record is said to "cover" the names between its
	owner name and next name.		owner name and next name.
	skipping to change at page 4, line 40 ¶		skipping to change at page 4, line 40 ¶
	document are to be interpreted as described in RFC 2119 [4].		document are to be interpreted as described in RFC 2119 [4].
	2. Applicability of This Technique		2. Applicability of This Technique
	The technique presented here may be useful to a zone owner that wants		The technique presented here may be useful to a zone owner that wants
	to use DNSSEC, is concerned about exposure of its zone contents via		to use DNSSEC, is concerned about exposure of its zone contents via
	zone walking, and is willing to bear the costs of on-line signing.		zone walking, and is willing to bear the costs of on-line signing.
	As discussed in Section 6, on-line signing has several security		As discussed in Section 6, on-line signing has several security
	risks, including an increased likelihood of private keys being		risks, including an increased likelihood of private keys being
	disclosed and an increased risk of denial of service attack. Due to		disclosed and an increased risk of denial of service attack. Anyone
	these concerns, this technique should only be used when the need to
	avoid exposure of zone contents is overwhelming. Anyone
	contemplating use of this technique is strongly encouraged to review		contemplating use of this technique is strongly encouraged to review
	the discussion of the risks of on-line signing in Section 6.		the discussion of the risks of on-line signing in Section 6.
	Furthermore, at the time this document was published, the DNSEXT		Furthermore, at the time this document was published, the DNSEXT
	working group was actively working on a mechanism to prevent zone		working group was actively working on a mechanism to prevent zone
	walking that does not require on-line signing (tentatively called		walking that does not require on-line signing (tentatively called
	NSEC3). This technique is likely to expose slightly more information		NSEC3). The new mechanism is likely to expose slightly more
	about the zone than this technique (e.g. the number of instantiated		information about the zone than this technique (e.g. the number of
	names), but it will still likely be preferable to this technique.		instantiated names), but it may be preferable to this technique.
	Anyone contemplating use of this technique is strongly encouraged to
	look for such future innovations.
	3. Minimally Covering NSEC Records		3. Minimally Covering NSEC Records
	This mechanism involves changes to NSEC records for instantiated		This mechanism involves changes to NSEC records for instantiated
	names, which can still be generated and signed in advance, as well as		names, which can still be generated and signed in advance, as well as
	the on-demand generation and signing of new NSEC records whenever a		the on-demand generation and signing of new NSEC records whenever a
	name must be proven not to exist.		name must be proven not to exist.
	In the 'next name' field of instantiated names' NSEC records, rather		In the 'next name' field of instantiated names' NSEC records, rather
	than list the next instantiated name in the zone, list any name that		than list the next instantiated name in the zone, list any name that
	skipping to change at page 5, line 32 ¶		skipping to change at page 5, line 29 ¶
	with all existing DNSSEC validators. These NSEC records are returned		with all existing DNSSEC validators. These NSEC records are returned
	whenever proving something specifically about the owner name (e.g.		whenever proving something specifically about the owner name (e.g.
	that no resource records of a given type appear at that name).		that no resource records of a given type appear at that name).
	Whenever an NSEC record is needed to prove the non-existence of a		Whenever an NSEC record is needed to prove the non-existence of a
	name, a new NSEC record is dynamically produced and signed. The new		name, a new NSEC record is dynamically produced and signed. The new
	NSEC record has an owner name lexically before the QNAME but		NSEC record has an owner name lexically before the QNAME but
	lexically following any existing name and a 'next name' lexically		lexically following any existing name and a 'next name' lexically
	following the QNAME but before any existing name.		following the QNAME but before any existing name.
	The generated NSEC record's type bitmap SHOULD have the RRSIG and		The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
	NSEC bits set and SHOULD NOT have any other bits set. This relaxes		bits set and SHOULD NOT have any other bits set. This relaxes the
	the requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at		requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
	names that did not exist before the zone was signed.		names that did not exist before the zone was signed.
	The functions to generate the lexically following and proceeding		The functions to generate the lexically following and proceeding
	names need not be perfect nor consistent, but the generated NSEC		names need not be perfect nor consistent, but the generated NSEC
	records must not cover any existing names. Furthermore, this		records must not cover any existing names. Furthermore, this
	technique works best when the generated NSEC records cover as few		technique works best when the generated NSEC records cover as few
	names as possible. In this document, the functions that generate the		names as possible. In this document, the functions that generate the
	nearby names are called 'epsilon' functions, a reference to the		nearby names are called 'epsilon' functions, a reference to the
	mathematical convention of using the greek letter epsilon to		mathematical convention of using the greek letter epsilon to
	represent small deviations.		represent small deviations.
	skipping to change at page 9, line 12 ¶		skipping to change at page 9, line 7 ¶
	[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	Many individuals contributed to this design. They include, in		Many individuals contributed to this design. They include, in
	addition to the authors of this document, Olaf Kolkman, Ed Lewis,		addition to the authors of this document, Olaf Kolkman, Ed Lewis,
	Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,		Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
	Jakob Schlyter, Bill Manning, and Joao Damas.		Jakob Schlyter, Bill Manning, and Joao Damas.
	In addition, the editors would like to thank Ed Lewis for his careful		In addition, the editors would like to thank Ed Lewis, Scott Rose,
	review of the document.		and David Blacka for their careful review of the document.
	Authors' Addresses		Authors' Addresses
	Samuel Weiler		Samuel Weiler
	SPARTA, Inc		SPARTA, Inc
	7075 Samuel Morse Drive		7075 Samuel Morse Drive
	Columbia, Maryland 21046		Columbia, Maryland 21046
	US		US
	Email: weiler@tislabs.com		Email: weiler@tislabs.com
End of changes. 9 change blocks.
	19 lines changed or deleted		22 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/