draft-ietf-dnsext-dnssec-algo-signal-04.txt		draft-ietf-dnsext-dnssec-algo-signal-05.txt
	DNS Extensions Working Group S. Crocker		DNS Extensions Working Group S. Crocker
	Internet-Draft Shinkuro Inc.		Internet-Draft Shinkuro Inc.
	Intended status: Standards Track S. Rose		Intended status: Standards Track S. Rose
	Expires: September 7, 2012 NIST		Expires: September 27, 2012 NIST
	March 6, 2012		March 26, 2012
	Signaling Cryptographic Algorithm Understanding in DNSSEC		Signaling Cryptographic Algorithm Understanding in DNSSEC
	draft-ietf-dnsext-dnssec-algo-signal-04		draft-ietf-dnsext-dnssec-algo-signal-05
	Abstract		Abstract
	The DNS Security Extensions (DNSSEC) were developed to provide origin		The DNS Security Extensions (DNSSEC) were developed to provide origin
	authentication and integrity protection for DNS data by using digital		authentication and integrity protection for DNS data by using digital
	signatures. These digital signatures can be generated using		signatures. These digital signatures can be generated using
	different algorithms. This draft sets out to specify a way for		different algorithms. This draft sets out to specify a way for
	validating end-system resolvers to signal to a server which		validating end-system resolvers to signal to a server which
	cryptographic algorithms and hash algorithms they support.		cryptographic algorithms and hash algorithms they support.
	skipping to change at page 1, line 42		skipping to change at page 1, line 42
	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 7, 2012.		This Internet-Draft will expire on September 27, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 6, line 47		skipping to change at page 6, line 47
	processing on the server side.		processing on the server side.
	If the options are present but the DNSSEC-OK (OK) bit is not set, the		If the options are present but the DNSSEC-OK (OK) bit is not set, the
	server does not do any DNSSEC processing, including any recording of		server does not do any DNSSEC processing, including any recording of
	the option(s).		the option(s).
	6. Traffic Analysis Considerations		6. Traffic Analysis Considerations
	Zone administrators that are planning or are in the process of a		Zone administrators that are planning or are in the process of a
	cryptographic algorithm rollover operation should monitor DNS query		cryptographic algorithm rollover operation should monitor DNS query
	traffic and record the values of the DAU/DHU/N3U option(s) in		traffic and record the number of queries, the presense of the OPT RR
	queries. This monitoring can measure the deployment of client code		in queries and the values of the DAU/DHU/N3U option(s) (if present).
	that implements (and signals) certain algorithms. Exactly how to		This monitoring can be used to measure the deployment of client code
			that implements (and signals) certain algorithms. The Exactly how to
	capture DNS traffic and measure new algorithm adoption is beyond the		capture DNS traffic and measure new algorithm adoption is beyond the
	scope of this document.		scope of this document.
	Zone administrators can use this data to set plans for starting an		Zone administrators that need to comply with changes to their
	algorithm rollover and determine when older algorithms can be phased		organization's security policy (with regards to cryptographic
	out without disrupting a significant number of clients. In order to		algorithm use) can use this data to set milestone dates for
	keep this disruption to a minimum, zone administrators should wait to		performing an algorithm rollover. For example, zone administrators
			can use the data to determine when older algorithms can be phased out
			without disrupting a significant number of clients. In order to keep
			this disruption to a minimum, zone administrators should wait to
	complete an algorithm rollover until a large majority of clients		complete an algorithm rollover until a large majority of clients
	signal that they understand the new algorithm. This may be in the		signal that they understand the new algorithm. This may be in the
	order of years rather than months. Note that clients that do not		order of years rather than months. Note that clients that do not
	implement these options are likely to be older implementations which		implement these options are likely to be older implementations which
	would also not implement any newly deployed algorithm.		would also not implement any newly deployed algorithm.
	7. IANA Considerations		7. IANA Considerations
	The algorithm codes used to identify DNSSEC algorithms, DS RR hash		The algorithm codes used to identify DNSSEC algorithms, DS RR hash
	algorithms and NSEC3 hash algorithms have already been established by		algorithms and NSEC3 hash algorithms have already been established by
End of changes. 5 change blocks.
	11 lines changed or deleted		15 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/