< draft-ietf-dnssec-secops-01.txt		draft-ietf-dnssec-secops-02.txt >
	DNS Security Working Group Donald E. Eastlake 3rd		DNS Security Working Group Donald E. Eastlake 3rd
	INTERNET-DRAFT CyberCash		INTERNET-DRAFT IBM
	Expires: September 1998 March 1998		Expires: May 1999 November 1998
	DNS Operational Security Considerations		DNS Security Operational Considerations
	--- ----------- -------- --------------		--- -------- ----------- --------------
	Status of This Document		Status of This Document
	This draft, file name draft-ietf-dnssec-secops-01.txt, is intended to		This draft, file name draft-ietf-dnssec-secops-02.txt, is intended to
	be become an Informational RFC. Some of this material was included in		be become a Best Current Practices RFC. An earlier version of some of
	[RFC 2065] but that RFC is obsoleted by [draft-ietf-dnssec-secext2-		this material was included in [RFC 2065] but that RFC is obsoleted by
	*.txt] which does not include this material. Distribution of this		[draft-ietf-dnssec-secext2-*.txt] which does not include this
	document is unlimited. Comments should be sent to the DNS Security		material. Distribution of this document is unlimited. Comments
	Working Group mailing list <dns-security@tis.com> or to the authors.		should be sent to the DNS Security Working Group mailing list <dns-
			security@tis.com> or to the authors.
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months. Internet-Drafts may be updated, replaced, or obsoleted by		months. Internet-Drafts may be updated, replaced, or obsoleted by
	other documents at any time. It is not appropriate to use Internet-		other documents at any time. It is not appropriate to use Internet-
	Drafts as reference material or to cite them other than as a		Drafts as reference material or to cite them other than as a
	``working draft'' or ``work in progress.''		``working draft'' or ``work in progress.''
	To learn the current status of any Internet-Draft, please check the		To view the entire list of current Internet-Drafts, please check the
	1id-abstracts.txt listing contained in the Internet-Drafts Shadow		"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
	Directories on ds.internic.net (East USA), ftp.isi.edu (West USA),		Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
	ftp.nordu.net (North Europe), ftp.nis.garr.it (South Europe),		Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
	munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa).		Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
			[Changes from last draft: update author info, file name, dates; add a
			paragraph about the problems with exessively short key liftetimes; up
			recommended RSA key size, drop overly specific root meta-key example]
	Abstract		Abstract
	Secure DNS is based on cryptographic techniques. A necessary part of		Secure DNS is based on cryptographic techniques. A necessary part of
	the strength of these techniques is careful attention to the		the strength of these techniques is careful attention to the
	operational aspects of key and signature generation, lifetime, size,		operational aspects of key and signature generation, lifetime, size,
	and storage. In addition, special attention must be paid to the		and storage. In addition, special attention must be paid to the
	security of the high level zones, particularly the root zone. This		security of the high level zones, particularly the root zone. This
	document discusses these operational aspects for keys and signatures		document discusses these operational aspects for keys and signatures
	used in connection with the KEY and SIG DNS resource records.		used in connection with the KEY and SIG DNS resource records.
	skipping to change at page 3, line 19 ¶		skipping to change at page 3, line 19 ¶
	Abstract...................................................2		Abstract...................................................2
	Acknowledgments............................................2		Acknowledgments............................................2
	Table of Contents..........................................3		Table of Contents..........................................3
	1. Introduction............................................4		1. Introduction............................................4
	2. Public/Private Key Generation...........................4		2. Public/Private Key Generation...........................4
	3. Public/Private Key Lifetimes............................4		3. Public/Private Key Lifetimes............................4
	4. Public/Private Key Size Considerations..................5		4. Public/Private Key Size Considerations..................5
	4.1 RSA Key Sizes..........................................5		4.1 RSA Key Sizes..........................................5
	4.2 DSS Key Sizes..........................................5		4.2 DSS Key Sizes..........................................6
	5. Private Key Storage.....................................6		5. Private Key Storage.....................................6
	6. High Level Zones, The Root Zone, and The Meta-Root Key..6		6. High Level Zones, The Root Zone, and The Meta-Root Key..6
	7. Security Considerations.................................8		7. Security Considerations.................................7
	References.................................................9		References.................................................8
	Author's Address..........................................10		Author's Address...........................................9
	Expiration and File Name..................................10		Expiration and File Name...................................9
	1. Introduction		1. Introduction
	This document describes operational considerations for the		This document describes operational considerations for the
	generation, lifetime, size, and storage of DNS cryptographic keys and		generation, lifetime, size, and storage of DNS cryptographic keys and
	signatures for use in the KEY and SIG resource records [draft-ietf-		signatures for use in the KEY and SIG resource records [draft-ietf-
	dnssec-secext2-*.txt]. Particular attention is paid to high level		dnssec-secext2-*.txt]. Particular attention is paid to high level
	zones and the root zone.		zones and the root zone.
	2. Public/Private Key Generation		2. Public/Private Key Generation
	Careful generation of all keys is a sometimes overlooked but		Careful generation of all keys is a sometimes overlooked but
	absolutely essential element in any cryptographically secure system.		absolutely essential element in any cryptographically secure system.
	The strongest algorithms used with the longest keys are still of no		The strongest algorithms used with the longest keys are still of no
	use if an adversary can guess enough to lower the size of the likely		use if an adversary can guess enough to lower the size of the likely
	key space so that it can be exhaustively searched. Technical		key space so that it can be exhaustively searched. Technical
	suggestions for the generation of random keys will be found in [RFC		suggestions for the generation of random keys will be found in [RFC
	1750].		1750].
	Long term keys are particularly sensitive as they will represent a		Long term keys are particularly sensitive as they will represent a
	more valuable target and be subject to attack for a longer timer than		more valuable target and be subject to attack for a longer time than
	short period keys. It is strongly recommended that long term key		short period keys. It is strongly recommended that long term key
	generation occur off-line in a manner isolated from the network via		generation occur off-line in a manner isolated from the network via
	an air gap or, at a minimum, high level secure hardware.		an air gap or, at a minimum, high level secure hardware.
	3. Public/Private Key Lifetimes		3. Public/Private Key Lifetimes
	No key should be used forever. The longer a key is in use, the		No key should be used forever. The longer a key is in use, the
	greater the probability that it will have been compromised through		greater the probability that it will have been compromised through
	carelessness, accident, espionage, or cryptanalysis. Furthermore, if		carelessness, accident, espionage, or cryptanalysis. Furthermore, if
	key rollover is a rare event, there is an increased risk that, when		key rollover is a rare event, there is an increased risk that, when
	the time does come to change the key, no one at the site will		the time does come to change the key, no one at the site will
	remember how to do it or operational problems will have developed in		remember how to do it or operational problems will have developed in
	the key rollover procedures.		the key rollover procedures.
	While public key lifetime is a matter of local policy, these		While public key lifetime is a matter of local policy, these
	considerations suggest that no long term key should have a lifetime		considerations imply that, unless there are extraordinary
	significantly over four years. In fact, a reasonable guideline for		circumstances, no long term key should have a lifetime significantly
	long term keys that are kept off-line and carefully guarded is a 13		over four years. In fact, a reasonable guideline for long term keys
	month lifetime with the intent that they be replaced every year. A		that are kept off-line and carefully guarded is a 13 month lifetime
	reasonable maximum lifetime for keys that are used for transaction		with the intent that they be replaced every year. A reasonable
	security or the like and are kept on line is 36 days with the intent		maximum lifetime for keys that are used for transaction security or
	that they be replaced monthly or more often. In many cases, a key		the like and are kept on line is 36 days with the intent that they be
	lifetime of somewhat over a day may be reasonable.		replaced monthly or more often. In many cases, a key lifetime of
			somewhat over a day may be reasonable.
			On the other hand, public keys with too short a lifetime can lead to
			excessive resource consumption in re-signing data and retrieving
			fresh information because cached information becomes stale. In the
			Internet environment, almost all public keys should have lifetimes no
			shorter than three minutes, which is a reasonable estimate of maximum
			packet delay even in unusual circumstances.
	4. Public/Private Key Size Considerations		4. Public/Private Key Size Considerations
	There are a number of factors that effect public key size choice for		There are a number of factors that effect public key size choice for
	use in the DNS security extension. Unfortunately, these factors		use in the DNS security extension. Unfortunately, these factors
	usually do not all point in the same direction. Choice of zone key		usually do not all point in the same direction. Choice of zone key
	size should generally be made by the zone administrator depending on		size should generally be made by the zone administrator depending on
	their local conditions.		their local conditions.
	For most schemes, larger keys are more secure but slower. In		For most schemes, larger keys are more secure but slower. In
	skipping to change at page 5, line 31 ¶		skipping to change at page 5, line 36 ¶
	operation) for the MD5/RSA algorithm will vary roughly with the		operation) for the MD5/RSA algorithm will vary roughly with the
	square of the modulus length, signing will vary with the cube of the		square of the modulus length, signing will vary with the cube of the
	modulus length, and key generation (the least common operation) will		modulus length, and key generation (the least common operation) will
	vary with the fourth power of the modulus length. The current best		vary with the fourth power of the modulus length. The current best
	algorithms for factoring a modulus and breaking RSA security vary		algorithms for factoring a modulus and breaking RSA security vary
	roughly with the 1.6 power of the modulus itself. Thus going from a		roughly with the 1.6 power of the modulus itself. Thus going from a
	640 bit modulus to a 1280 bit modulus only increases the verification		640 bit modulus to a 1280 bit modulus only increases the verification
	time by a factor of 4 but may increase the work factor of breaking		time by a factor of 4 but may increase the work factor of breaking
	the key by over 2^900.		the key by over 2^900.
	The recommended minimum RSA algorithm modulus size, 640 bits, is		The recommended minimum RSA algorithm modulus size is 704 bits which
	believed by the author to be secure at this time but high level zones		is believed by the author to be secure at this time. But high level
	in the DNS tree may wish to set a higher minimum, perhaps 1000 bits,		zones in the DNS tree may wish to set a higher minimum, perhaps 1000
	for security reasons. (Since the United States National Security		bits, for security reasons. (Since the United States National
	Agency generally permits export of encryption systems using an RSA		Security Agency generally permits export of encryption systems using
	modulus of up to 512 bits, use of that small a modulus, i.e. n, must		an RSA modulus of up to 512 bits, use of that small a modulus, i.e.
	be considered weak.)		n, must be considered weak.)
	For an RSA key used only to secure data and not to secure other keys,		For an RSA key used only to secure data and not to secure other keys,
	640 bits should be adequate at this time.		704 bits should be adequate at this time.
	4.2 DSS Key Sizes		4.2 DSS Key Sizes
	DSS keys are probably roughly as strong as an RSA key of the same		DSS keys are probably roughly as strong as an RSA key of the same
	length but DSS signatures are significantly smaller.		length but DSS signatures are significantly smaller.
	5. Private Key Storage		5. Private Key Storage
	It is recommended that, where possible, zone private keys and the		It is recommended that, where possible, zone private keys and the
	zone file master copy be kept and used in off-line non-network		zone file master copy be kept and used in off-line, non-network
	connected physically secure machines only. Periodically an		connected, physically secure machines only. Periodically an
	application can be run to add authentication to a zone by adding SIG		application can be run to add authentication to a zone by adding SIG
	and NXT RRs and adding no-key type KEY RRs for subzones/algorithms		and NXT RRs and adding no-key type KEY RRs for subzones/algorithms
	where a real KEY RR for the subzone with that algorithm is not		where a real KEY RR for the subzone with that algorithm is not
	provided. Then the augmented file can be transferred, perhaps by		provided. Then the augmented file can be transferred, perhaps by
	sneaker-net, to the networked zone primary server machine.		sneaker-net, to the networked zone primary server machine.
	The idea is to have a one way information flow to the network to		The idea is to have a one way information flow to the network to
	avoid the possibility of tampering from the network. Keeping the		avoid the possibility of tampering from the network. Keeping the
	zone master file on-line on the network and simply cycling it through		zone master file on-line on the network and simply cycling it through
	an off-line signer does not do this. The on-line version could still		an off-line signer does not do this. The on-line version could still
	be tampered with if the host it resides on is compromised. For		be tampered with if the host it resides on is compromised. For
	maximum security, the master copy of the zone file should be off net		maximum security, the master copy of the zone file should be off net
	and should not be updated based on an unsecured network mediated		and should not be updated based on an unsecured network mediated
	communication.		communication.
	This is not possible if the zone is to be dynamically updated		This is not possible if the zone is to be dynamically updated
	securely [RFC 2137]. At least a private key capable of updating the		securely [RFC 2137]. At least a private key capable of updating the
	SOA and NXT chain must be one line in that case.		SOA and NXT chain must be on line in that case.
	Secure resolvers must be configured with some trusted on-line public		Secure resolvers must be configured with some trusted on-line public
	key information (or a secure path to such a resolver) or they will be		key information (or a secure path to such a resolver) or they will be
	unable to authenticate. Although on line, this public key		unable to authenticate. Although on line, this public key
	information must be protected or it could be altered so that spoofed		information must be protected or it could be altered so that spoofed
	DNS data would appear authentic.		DNS data would appear authentic.
	Non-zone private keys, such as host or user keys, generally have to		Non-zone private keys, such as host or user keys, generally have to
	be kept on line to be used for real-time purposes such as DNS		be kept on line to be used for real-time purposes such as DNS
	transaction security.		transaction security.
	skipping to change at page 7, line 13 ¶		skipping to change at page 7, line 20 ¶
	of a subdomain). Therefore, the utmost care must be taken in the		of a subdomain). Therefore, the utmost care must be taken in the
	securing of the root zone. The strongest and most carefully handled		securing of the root zone. The strongest and most carefully handled
	keys should be used. The root zone private key should always be kept		keys should be used. The root zone private key should always be kept
	off line.		off line.
	Many resolvers will start at a root server for their access to and		Many resolvers will start at a root server for their access to and
	authentication of DNS data. Securely updating an enormous population		authentication of DNS data. Securely updating an enormous population
	of resolvers around the world will be extremely difficult. Yet the		of resolvers around the world will be extremely difficult. Yet the
	guidelines in section 3 above would imply that the root zone private		guidelines in section 3 above would imply that the root zone private
	key be changed annually or more often and if it were staticly		key be changed annually or more often and if it were staticly
	configured at all these resolvers, it would have to be updaed when		configured at all these resolvers, it would have to be updated when
	changed.		changed.
	To permit relatively frequent change to the root zone key yet		To permit relatively frequent change to the root zone key yet
	minimize exposure of the ultimate key of the DNS tree, there will be		minimize exposure of the ultimate key of the DNS tree, there will be
	a "meta-root" key used very rarely and then only to sign a sequence		a "meta-root" key used very rarely and then only to sign a sequence
	of regular root key RRsets with overlapping time validity periods		of regular root key RRsets with overlapping time validity periods
	that are to be rolled out. The root zone contains the meta-root and		that are to be rolled out. The root zone contains the meta-root and
	current regular root KEY RR(s) signed by SIG RRs under both the		current regular root KEY RR(s) signed by SIG RRs under both the
	meta-root and other root private key(s) themselves.		meta-root and other root private key(s) themselves.
	For example, assume that the regular root zone key is to be changed
	once a month. If the meta-root key were to be exposed only once a
	year, then for each exposure you might use the meta-key to sign
	twenty four key RRsets as follows:
	one with a date signed of the middle of January and expiring the
	middle of February with the January and Jan/Feb root keys,
	one with a date signed of the beginning of February and expiring
	the end of February with the Jan/Feb and February root keys,
	one with a date signed of the middle of February and expiring
	the middle of March with the February and Feb/Mar root keys,
	one with the data signed of the beginning of March and expiring
	the end of March with the Feb/Mar and March root keys,
	etc.
	During the first half of January, the data in the root zone with the
	above hypothetical key policy would be signed with the Dec/Jan and
	January keys. During the second half of January, it would be signed
	with the January and Jan/Feb keys. During the first half of
	February, it would be signed with the Jan/Feb and February keys. Etc.
	The utmost security in the storage and use of the meta-root key is		The utmost security in the storage and use of the meta-root key is
	essential. The exact techniques are precautions to be used are		essential. The exact techniques are precautions to be used are
	beyond the scope of this document. Because of its special position,		beyond the scope of this document. Because of its special position,
	it may be best to continue with the same meta-root key for an		it may be best to continue with the same meta-root key for an
	extended period of time such as ten to fifteen years.		extended period of time such as ten to fifteen years.
	7. Security Considerations		7. Security Considerations
	The entirety of this document is concerned with operational		The entirety of this document is concerned with operational
	considerations of public/private key pair DNS Security.		considerations of public/private key pair DNS Security.
	skipping to change at page 10, line 8 ¶		skipping to change at page 9, line 8 ¶
	Update", 04/21/1997.		Update", 04/21/1997.
	draft-ietf-dnssec-secext2-*.txt - D. Eastlake, "Domain Name System		draft-ietf-dnssec-secext2-*.txt - D. Eastlake, "Domain Name System
	Security Extensions".		Security Extensions".
	[RSA FAQ] - RSADSI Frequently Asked Questions periodic posting.		[RSA FAQ] - RSADSI Frequently Asked Questions periodic posting.
	Author's Address		Author's Address
	Donald E. Eastlake 3rd		Donald E. Eastlake 3rd
	CyberCash, Inc.		IBM
	318 Acton Street		318 Acton Street
	Carlisle, MA 01741 USA		Carlisle, MA 01741 USA
	Telephone: +1 978-287-4877		Telephone: +1 978-287-4877
	+1 703-620-4200 (main office, Reston, Virginia, USA)		+1 914-784-7913
	fax: +1 978-371-7148		fax: +1 978-371-7148
	email: dee@cybercash.com		email: dee3@us.ibm.com
	Expiration and File Name		Expiration and File Name
	This draft expires September 1998.		This draft expires May 1999.
	Its file name is draft-ietf-dnssec-secops-01.txt.		Its file name is draft-ietf-dnssec-secops-02.txt.
End of changes. 22 change blocks.
	67 lines changed or deleted		60 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/