< draft-ietf-dnsop-dns-zone-digest-11.txt		draft-ietf-dnsop-dns-zone-digest-12.txt >
	Internet Engineering Task Force D. Wessels		Internet Engineering Task Force D. Wessels
	Internet-Draft P. Barber		Internet-Draft P. Barber
	Intended status: Standards Track Verisign		Intended status: Standards Track Verisign
	Expires: March 29, 2021 M. Weinberg		Expires: April 2, 2021 M. Weinberg
	Amazon		Amazon
	W. Kumari		W. Kumari
	Google		Google
	W. Hardaker		W. Hardaker
	USC/ISI		USC/ISI
	September 25, 2020		September 29, 2020
	Message Digest for DNS Zones		Message Digest for DNS Zones
	draft-ietf-dnsop-dns-zone-digest-11		draft-ietf-dnsop-dns-zone-digest-12
	Abstract		Abstract
	This document describes a protocol and new DNS Resource Record that		This document describes a protocol and new DNS Resource Record that
	provides a cryptographic message digest over DNS zone data. The		provides a cryptographic message digest over DNS zone data. The
	ZONEMD Resource Record conveys the digest data in the zone itself.		ZONEMD Resource Record conveys the digest data in the zone itself.
	When a zone publisher includes a ZONEMD record, recipients can verify		When a zone publisher includes a ZONEMD record, recipients can verify
	the zone contents for accuracy and completeness. This provides		the zone contents for accuracy and completeness. This provides
	assurance that received zone data matches published data, regardless		assurance that received zone data matches published data, regardless
	of how the zone data has been transmitted and received.		of how the zone data has been transmitted and received.
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 March 29, 2021.		This Internet-Draft will expire on April 2, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 3, line 11 ¶		skipping to change at page 3, line 11 ¶
	3.3. Scheme-Specific Processing . . . . . . . . . . . . . . . 11		3.3. Scheme-Specific Processing . . . . . . . . . . . . . . . 11
	3.3.1. The SIMPLE Scheme . . . . . . . . . . . . . . . . . . 11		3.3.1. The SIMPLE Scheme . . . . . . . . . . . . . . . . . . 11
	3.3.1.1. SIMPLE Scheme Inclusion/Exclusion Rules . . . . . 11		3.3.1.1. SIMPLE Scheme Inclusion/Exclusion Rules . . . . . 11
	3.3.1.2. SIMPLE Scheme Digest Calculation . . . . . . . . 12		3.3.1.2. SIMPLE Scheme Digest Calculation . . . . . . . . 12
	3.4. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 12		3.4. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 12
	4. Verifying Zone Digest . . . . . . . . . . . . . . . . . . . . 12		4. Verifying Zone Digest . . . . . . . . . . . . . . . . . . . . 12
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	5.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 14		5.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 14
	5.2. ZONEMD Scheme . . . . . . . . . . . . . . . . . . . . . . 14		5.2. ZONEMD Scheme . . . . . . . . . . . . . . . . . . . . . . 14
	5.3. ZONEMD Hash Algorithm . . . . . . . . . . . . . . . . . . 15		5.3. ZONEMD Hash Algorithm . . . . . . . . . . . . . . . . . . 15
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 16		6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	6.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 16		6.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 16
	6.2. DNSSESC Timing Considerations . . . . . . . . . . . . . . 16		6.2. DNSSESC Timing Considerations . . . . . . . . . . . . . . 16
	6.3. Attacks Utilizing ZONEMD Queries . . . . . . . . . . . . 16		6.3. Attacks Utilizing ZONEMD Queries . . . . . . . . . . . . 16
	6.4. Resilience and Fragility . . . . . . . . . . . . . . . . 17		6.4. Resilience and Fragility . . . . . . . . . . . . . . . . 17
	7. Performance Considerations . . . . . . . . . . . . . . . . . 17		7. Performance Considerations . . . . . . . . . . . . . . . . . 17
	7.1. SIMPLE SHA384 . . . . . . . . . . . . . . . . . . . . . . 17		7.1. SIMPLE SHA384 . . . . . . . . . . . . . . . . . . . . . . 17
	8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
	10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18		10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
	11.1. Normative References . . . . . . . . . . . . . . . . . . 24		11.1. Normative References . . . . . . . . . . . . . . . . . . 25
	11.2. Informative References . . . . . . . . . . . . . . . . . 25		11.2. Informative References . . . . . . . . . . . . . . . . . 25
	Appendix A. Example Zones With Digests . . . . . . . . . . . . . 27		Appendix A. Example Zones With Digests . . . . . . . . . . . . . 28
	A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 27		A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 28
	A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 28		A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 28
	A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 29		A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 29
	A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 29		A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 30
	A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 32		A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 33
	Appendix B. Implementation Status . . . . . . . . . . . . . . . 34		Appendix B. Implementation Status . . . . . . . . . . . . . . . 35
	B.1. Authors' Implementation . . . . . . . . . . . . . . . . . 34		B.1. Authors' Implementation . . . . . . . . . . . . . . . . . 35
	B.2. Shane Kerr's Implementation . . . . . . . . . . . . . . . 34		B.2. Shane Kerr's Implementation . . . . . . . . . . . . . . . 35
	B.3. NIC Chile Labs Implementation . . . . . . . . . . . . . . 35		B.3. NIC Chile Labs Implementation . . . . . . . . . . . . . . 36
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
	1. Introduction		1. Introduction
	In the DNS, a zone is the collection of authoritative resource		In the DNS, a zone is the collection of authoritative resource
	records (RRs) sharing a common origin ([RFC8499]). Zones are often		records (RRs) sharing a common origin ([RFC8499]). Zones are often
	stored as files in the so-called master file format [RFC1034]. Zones		stored as files in the so-called master file format [RFC1034]. Zones
	are generally distributed among name servers using the AXFR (zone		are generally distributed among name servers using the AXFR (zone
	transfer [RFC5936]), and IXFR (incremental zone transfer [RFC1995])		transfer [RFC5936]), and IXFR (incremental zone transfer [RFC1995])
	protocols. They can also be distributed outside of the DNS, with any		protocols. They can also be distributed outside of the DNS, with any
	file transfer protocol such as FTP, HTTP, and rsync, or even as email		file transfer protocol such as FTP, HTTP, and rsync, or even as email
	skipping to change at page 8, line 10 ¶		skipping to change at page 8, line 10 ¶
	This section describes the ZONEMD Resource Record, including its		This section describes the ZONEMD Resource Record, including its
	fields, wire format, and presentation format. The Type value for the		fields, wire format, and presentation format. The Type value for the
	ZONEMD RR is 63. The ZONEMD RR is class independent. The RDATA of		ZONEMD RR is 63. The ZONEMD RR is class independent. The RDATA of
	the resource record consists of four fields: Serial, Scheme, Hash		the resource record consists of four fields: Serial, Scheme, Hash
	Algorithm, and Digest.		Algorithm, and Digest.
	A zone MAY contain multiple ZONEMD RRs to support algorithm agility		A zone MAY contain multiple ZONEMD RRs to support algorithm agility
	[RFC7696] and rollovers. When multiple ZONEMD RRs are present, each		[RFC7696] and rollovers. When multiple ZONEMD RRs are present, each
	must specify a unique Scheme and Hash Algorithm tuple. It is		must specify a unique Scheme and Hash Algorithm tuple. It is
	recommended that a zone include only one ZONEMD RR, unless the zone		RECOMMENDED that a zone include only one ZONEMD RR, unless the zone
	publisher is in the process of transitioning to a new Scheme or Hash		publisher is in the process of transitioning to a new Scheme or Hash
	Algorithm.		Algorithm.
	2.1. Non-apex ZONEMD Records		2.1. Non-apex ZONEMD Records
	This document specifies ZONEMD RRs located at the zone apex. Non-		This document specifies ZONEMD RRs located at the zone apex. Non-
	apex ZONEMD RRs are not forbidden, but have no meaning in this		apex ZONEMD RRs are not forbidden, but have no meaning in this
	specification. Non-apex ZONEMD RRs MUST NOT be used for		specification. Non-apex ZONEMD RRs MUST NOT be used for
	verification.		verification.
	skipping to change at page 9, line 5 ¶		skipping to change at page 8, line 50 ¶
	/ /		/ /
	/ /		/ /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	2.2.1. The Serial Field		2.2.1. The Serial Field
	The Serial field is a 32-bit unsigned integer in network byte order.		The Serial field is a 32-bit unsigned integer in network byte order.
	It is the serial number from the zone's SOA record ([RFC1035] section		It is the serial number from the zone's SOA record ([RFC1035] section
	3.3.13) for which the zone digest was generated.		3.3.13) for which the zone digest was generated.
	It is included here in order to make DNS response messages of type		It is included here to clearly bind the ZONEMD RR to a particular
	ZONEMD meaningful. Without the serial number, a stand-alone ZONEMD		version of the zone's content. Without the serial number, a stand-
	digest has no association to any particular instance of a zone.		alone ZONEMD digest has no obvious association to any particular
			instance of a zone.
	2.2.2. The Scheme Field		2.2.2. The Scheme Field
	The Scheme field is an 8-bit unsigned integer that identifies the		The Scheme field is an 8-bit unsigned integer that identifies the
	methods by which data is collated and presented as input to the		methods by which data is collated and presented as input to the
	hashing function.		hashing function.
	Herein, SIMPLE, with value 1, is the only standardized Scheme defined		Herein, SIMPLE, with value 1, is the only standardized Scheme defined
	for ZONEMD records and it MUST be implemented. The Scheme registry		for ZONEMD records and it MUST be implemented. The Scheme registry
	is further described in Section 5.		is further described in Section 5.
	skipping to change at page 11, line 12 ¶		skipping to change at page 11, line 12 ¶
	algorithm rollover, each MUST specify a unique Scheme and Hash		algorithm rollover, each MUST specify a unique Scheme and Hash
	Algorithm tuple.		Algorithm tuple.
	It is RECOMMENDED that the TTL of the ZONEMD record match the TTL of		It is RECOMMENDED that the TTL of the ZONEMD record match the TTL of
	the SOA. However, the TTL of the ZONEMD record may be safely ignored		the SOA. However, the TTL of the ZONEMD record may be safely ignored
	during verification in all cases.		during verification in all cases.
	In the placeholder record, the Serial field is set to the current SOA		In the placeholder record, the Serial field is set to the current SOA
	Serial. The Scheme field is set to the value for the chosen		Serial. The Scheme field is set to the value for the chosen
	collation scheme. The Hash Algorithm field is set to the value for		collation scheme. The Hash Algorithm field is set to the value for
	the chosen hash algorithm. Since ZONEMD records are excluded from		the chosen hash algorithm. Since apex ZONEMD records are excluded
	digest calculation, the value of the Digest field does not matter at		from digest calculation, the value of the Digest field does not
	this point in the process.		matter at this point in the process.
	3.2. Optionally Sign the Zone		3.2. Optionally Sign the Zone
	Following addition of placeholder records, the zone may be signed		Following addition of placeholder records, the zone may be signed
	with DNSSEC. When the digest calculation is complete, and the ZONEMD		with DNSSEC. When the digest calculation is complete, and the ZONEMD
	record is updated, the signature(s) for the ZONEMD RRSet MUST be		record is updated, the signature(s) for the ZONEMD RRSet MUST be
	recalculated and updated as well. Therefore, the signer is not		recalculated and updated as well. Therefore, the signer is not
	required to calculate a signature over the placeholder record at this		required to calculate a signature over the placeholder record at this
	step in the process, but it is harmless to do so.		step in the process, but it is harmless to do so.
	skipping to change at page 12, line 9 ¶		skipping to change at page 12, line 9 ¶
	exclusion rules apply:		exclusion rules apply:
	o All records in the zone, including glue records, MUST be included.		o All records in the zone, including glue records, MUST be included.
	o Occluded data ([RFC5936] Section 3.5) MUST be included.		o Occluded data ([RFC5936] Section 3.5) MUST be included.
	o If there are duplicate RRs with equal owner, class, type, and		o If there are duplicate RRs with equal owner, class, type, and
	RDATA, only one instance is included ([RFC4034] Section 6.3), and		RDATA, only one instance is included ([RFC4034] Section 6.3), and
	the duplicates MUST be omitted.		the duplicates MUST be omitted.
	o The placeholder ZONEMD RR(s) MUST NOT be included.		o The placeholder apex ZONEMD RR(s) MUST NOT be included.
	o If the zone is signed, DNSSEC RRs MUST be included, except:		o If the zone is signed, DNSSEC RRs MUST be included, except:
	o The RRSIG covering ZONEMD MUST NOT be included because the RRSIG		o The RRSIG covering the apex ZONEMD RRSet MUST NOT be included
	will be updated after all digests have been calculated.		because the RRSIG will be updated after all digests have been
			calculated.
	3.3.1.2. SIMPLE Scheme Digest Calculation		3.3.1.2. SIMPLE Scheme Digest Calculation
	A zone digest using the SIMPLE scheme is calculated by concatenating		A zone digest using the SIMPLE scheme is calculated by concatenating
	all RRs in the zone, in the format and order described in		all RRs in the zone, in the format and order described in
	Section 3.3.1 subject to the inclusion/exclusion rules described in		Section 3.3.1 subject to the inclusion/exclusion rules described in
	Section 3.3.1.1, and then applying the chosen hash algorithm:		Section 3.3.1.1, and then applying the chosen hash algorithm:
	digest = hash( RR(1) | RR(2) | RR(3) | ... )		digest = hash( RR(1) | RR(2) | RR(3) | ... )
	skipping to change at page 14, line 4 ¶		skipping to change at page 14, line 4 ¶
	does not support the given hash algorithm, verification MUST		does not support the given hash algorithm, verification MUST
	NOT be considered successful with this ZONEMD RR and it		NOT be considered successful with this ZONEMD RR and it
	SHOULD report that the RR's digest could not be verified due		SHOULD report that the RR's digest could not be verified due
	to an unsupported algorithm.		to an unsupported algorithm.
	D. The Digest field size MUST be checked. If the size of the		D. The Digest field size MUST be checked. If the size of the
	given Digest field is smaller than 12 octets, or if the size		given Digest field is smaller than 12 octets, or if the size
	is not equal to the size expected for the corresponding Hash		is not equal to the size expected for the corresponding Hash
	Algorithm, verification MUST NOT be considered successful		Algorithm, verification MUST NOT be considered successful
	with this ZONEMD RR and the verifier SHOULD report that the		with this ZONEMD RR and the verifier SHOULD report that the
	RR's digest could not be verified to to an incorrect digest		RR's digest could not be verified due to an incorrect digest
	length.		length.
	E. The zone digest is computed over the zone data as described		E. The zone digest is computed over the zone data as described
	in Section 3.3, using the Scheme and Hash Algorithm for the		in Section 3.3, using the Scheme and Hash Algorithm for the
	current ZONEMD RR.		current ZONEMD RR.
	F. The computed digest is compared to the received digest. If		F. The computed digest is compared to the received digest. If
	the two digest values match, verification is considered		the two digest values match, verification is considered
	successful. Otherwise, verification MUST NOT be considered		successful. Otherwise, verification MUST NOT be considered
	successful for this ZONEMD RR.		successful for this ZONEMD RR.
	skipping to change at page 15, line 47 ¶		skipping to change at page 15, line 47 ¶
	| 2 | SHA-512 | SHA512 | SHOULD | [this |		| 2 | SHA-512 | SHA512 | SHOULD | [this |
	| | | | | document] |		| | | | | document] |
	| 3-239 | Unassigned | | | |		| 3-239 | Unassigned | | | |
	| 240-254 | Private Use | N/A | N/A | [his |		| 240-254 | Private Use | N/A | N/A | [his |
	| | | | | document] |		| | | | | document] |
	| 255 | Reserved | | | |		| 255 | Reserved | | | |
	+---------+-------------+----------+-------------------+------------+		+---------+-------------+----------+-------------------+------------+
	Table 2: ZONEMD Hash Algorithm Registry		Table 2: ZONEMD Hash Algorithm Registry
	The IANA policy for assigning new values to the ZONEMD Hash Algorithm
	registry shall be Specification Required.
	6. Security Considerations		6. Security Considerations
	6.1. Attacks Against the Zone Digest		6.1. Attacks Against the Zone Digest
	The zone digest allows the recipient of a zone to verify its		The zone digest allows the recipient of a zone to verify its
	integrity. In conjunction with DNSSEC, the recipient can		integrity. In conjunction with DNSSEC, the recipient can
	authenticate that it is as published by the zone originator.		authenticate that it is as published by the zone originator.
	An attacker, whose goal is to modify zone content before it is used		An attacker, whose goal is to modify zone content before it is used
	by the victim, may consider a number of different approaches.		by the victim, may consider a number of different approaches.
	The attacker might perform a downgrade attack to an unsigned zone.		The attacker might perform a downgrade attack to an unsigned zone.
	skipping to change at page 16, line 37 ¶		skipping to change at page 16, line 34 ¶
	DNSSEC validation.		DNSSEC validation.
	6.2. DNSSESC Timing Considerations		6.2. DNSSESC Timing Considerations
	As with all DNSSEC signatures, the ability to perform signature		As with all DNSSEC signatures, the ability to perform signature
	validation of a ZONEMD record is limited in time. If the DS		validation of a ZONEMD record is limited in time. If the DS
	record(s) or trust anchors for the zone to be verified are no longer		record(s) or trust anchors for the zone to be verified are no longer
	available, the recipient cannot validate the ZONEMD RRSet. This		available, the recipient cannot validate the ZONEMD RRSet. This
	could happen even if the ZONEMD signature is still current (not		could happen even if the ZONEMD signature is still current (not
	expired), since the zone's DS record(s) may have been withdrawn		expired), since the zone's DS record(s) may have been withdrawn
	following a KSK rollover.		following a Key Signing Key (KSK) rollover.
	For zones where it may be important to validate a ZONEMD RRSet		For zones where it may be important to validate a ZONEMD RRSet
	through its entire signature validity period, the zone operator		through its entire signature validity period, the zone operator
	should ensure that KSK rollover timing takes this into consideration.		should ensure that KSK rollover timing takes this into consideration.
	6.3. Attacks Utilizing ZONEMD Queries		6.3. Attacks Utilizing ZONEMD Queries
	Nothing in this specification prevents clients from making, and		Nothing in this specification prevents clients from making, and
	servers from responding to, ZONEMD queries. Servers SHOULD NOT		servers from responding to, ZONEMD queries. Servers SHOULD NOT
	calculate zone digests dynamically (for each query) as this can be		calculate zone digests dynamically (for each query) as this can be
	used as a CPU resource exhaustion attack.		used as a CPU resource exhaustion attack.
	ZONEMD responses could be used in a distributed denial-of-service		ZONEMD responses could be used in a distributed denial-of-service
	amplification attack. The ZONEMD RR is moderately sized, much like		amplification attack. The ZONEMD RR is moderately sized, much like
	the DS RR. A single ZONEMD RR contributes approximately 40 to 65		the DS RR. A single ZONEMD RR contributes approximately 65 to 95
	octets to a DNS response, for digest types defined herein. Other RR		octets to a DNS response, for digest types defined herein. Other RR
	types, such as DNSKEY, can result in larger amplification effects.		types, such as DNSKEY, can result in larger amplification effects.
	6.4. Resilience and Fragility		6.4. Resilience and Fragility
	ZONEMD is used to detect incomplete or corrupted zone data prior to		ZONEMD is used to detect incomplete or corrupted zone data prior to
	its use, thereby increasing resilience by not using corrupt data, but		its use, thereby increasing resilience by not using corrupt data, but
	also introduces some denial-of-service fragility by making good data		also introduces some denial-of-service fragility by making good data
	in a zone unavailable if some other data is missing or corrupt.		in a zone unavailable if some other data is missing or corrupt.
	Publishers and consumers of zones containing ZONEMD records should be		Publishers and consumers of zones containing ZONEMD records should be
	aware of these tradeoffs. While the intention is to secure the zone		aware of these tradeoffs. While the intention is to secure the zone
	data, misconfigurations or implementation bugs are generally		data, misconfigurations or implementation bugs are generally
	indistinguishable from intentional tampering, and could lead to		indistinguishable from intentional tampering, and could lead to
	service failures when verification is performed automatically.		service failures when verification is performed automatically.
	Zone publishers may want to deploy ZONEMD gradually, perhaps by		Zone publishers may want to deploy ZONEMD gradually, perhaps by
	utilizing one of the private use hash algorithms listed in		utilizing one of the private use hash algorithm code points listed in
	Section 5.3. Similarly, recipients may want to initially configure		Section 5.3. Similarly, recipients may want to initially configure
	verification failures only as a warning, and later as an error after		verification failures only as a warning, and later as an error after
	gaining experience and confidence with the feature.		gaining experience and confidence with the feature.
	7. Performance Considerations		7. Performance Considerations
	This section is provided to make zone publishers aware of the		This section is provided to make zone publishers aware of the
	performance requirements and implications of including ZONEMD RRs in		performance requirements and implications of including ZONEMD RRs in
	a zone.		a zone.
	skipping to change at page 24, line 40 ¶		skipping to change at page 24, line 40 ¶
	o Fixed people's names in the acknowledgments section (blush)		o Fixed people's names in the acknowledgments section (blush)
	o Say "has not been modified between origination and retrieval."		o Say "has not been modified between origination and retrieval."
	o Say that ZONEMD TTL doesn't matter during verification.		o Say that ZONEMD TTL doesn't matter during verification.
	o Further clarification that the SHA-384 and SHA-512 hashes are not		o Further clarification that the SHA-384 and SHA-512 hashes are not
	truncated. Future algs might be truncated, but never below 96		truncated. Future algs might be truncated, but never below 96
	bits.		bits.
			From -11 to -12:
			o SECDIR review: make "recommended" all caps.
			o SECDIR review: tweak explanation of why ZONEMD RR has copy of SOA
			serial.
			o SECDIR review: be even more clear about apex ZONEMD RRs vs non-
			apex.
			o SECDIR review: Forgot to delete sentence about IANA policy for
			adding new hash algorithms.
			o SECDIR review: Spell out Key Signing Key first time.
			o SECDIR review: say "private use hash algorithm code points."
			o SECDIR review: Update estimates of ZONEMD RR size.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,		STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
	<https://www.rfc-editor.org/info/rfc1034>.		<https://www.rfc-editor.org/info/rfc1034>.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
End of changes. 20 change blocks.
	34 lines changed or deleted		51 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/