< draft-ietf-dnsop-dns-zone-digest-10.txt		draft-ietf-dnsop-dns-zone-digest-11.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 25, 2021 M. Weinberg		Expires: March 29, 2021 M. Weinberg
	Amazon		Amazon
	W. Kumari		W. Kumari
	Google		Google
	W. Hardaker		W. Hardaker
	USC/ISI		USC/ISI
	September 21, 2020		September 25, 2020
	Message Digest for DNS Zones		Message Digest for DNS Zones
	draft-ietf-dnsop-dns-zone-digest-10		draft-ietf-dnsop-dns-zone-digest-11
	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 25, 2021.		This Internet-Draft will expire on March 29, 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 2, line 44 ¶		skipping to change at page 2, line 44 ¶
	1.4.4. Centralized Zone Data Service . . . . . . . . . . . . 7		1.4.4. Centralized Zone Data Service . . . . . . . . . . . . 7
	1.4.5. General Purpose Comparison Check . . . . . . . . . . 7		1.4.5. General Purpose Comparison Check . . . . . . . . . . 7
	1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7		1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
	2. The ZONEMD Resource Record . . . . . . . . . . . . . . . . . 7		2. The ZONEMD Resource Record . . . . . . . . . . . . . . . . . 7
	2.1. Non-apex ZONEMD Records . . . . . . . . . . . . . . . . . 8		2.1. Non-apex ZONEMD Records . . . . . . . . . . . . . . . . . 8
	2.2. ZONEMD RDATA Wire Format . . . . . . . . . . . . . . . . 8		2.2. ZONEMD RDATA Wire Format . . . . . . . . . . . . . . . . 8
	2.2.1. The Serial Field . . . . . . . . . . . . . . . . . . 8		2.2.1. The Serial Field . . . . . . . . . . . . . . . . . . 8
	2.2.2. The Scheme Field . . . . . . . . . . . . . . . . . . 9		2.2.2. The Scheme Field . . . . . . . . . . . . . . . . . . 9
	2.2.3. The Hash Algorithm Field . . . . . . . . . . . . . . 9		2.2.3. The Hash Algorithm Field . . . . . . . . . . . . . . 9
	2.2.4. The Digest Field . . . . . . . . . . . . . . . . . . 9		2.2.4. The Digest Field . . . . . . . . . . . . . . . . . . 9
	2.3. ZONEMD Presentation Format . . . . . . . . . . . . . . . 9		2.3. ZONEMD Presentation Format . . . . . . . . . . . . . . . 10
	2.4. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 10		2.4. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 10
	3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 10		3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 10
	3.1. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 10		3.1. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 10
	3.2. Optionally Sign the Zone . . . . . . . . . . . . . . . . 11		3.2. Optionally Sign the Zone . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 14		5.3. ZONEMD Hash Algorithm . . . . . . . . . . . . . . . . . . 15
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 15		6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	6.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 15		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 . . . . . . . . . . . . . . . . 16		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 . . . . . . . . . . . . . . . . . . . . . . . . . 24
	11.1. Normative References . . . . . . . . . . . . . . . . . . 24		11.1. Normative References . . . . . . . . . . . . . . . . . . 24
	11.2. Informative References . . . . . . . . . . . . . . . . . 24		11.2. Informative References . . . . . . . . . . . . . . . . . 25
	Appendix A. Example Zones With Digests . . . . . . . . . . . . . 27		Appendix A. Example Zones With Digests . . . . . . . . . . . . . 27
	A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 27		A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 27
	A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 27		A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 28
	A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 28		A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 29
	A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 29		A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 29
	A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 32		A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 32
	Appendix B. Implementation Status . . . . . . . . . . . . . . . 34		Appendix B. Implementation Status . . . . . . . . . . . . . . . 34
	B.1. Authors' Implementation . . . . . . . . . . . . . . . . . 34		B.1. Authors' Implementation . . . . . . . . . . . . . . . . . 34
	B.2. Shane Kerr's Implementation . . . . . . . . . . . . . . . 34		B.2. Shane Kerr's Implementation . . . . . . . . . . . . . . . 34
	B.3. NIC Chile Labs Implementation . . . . . . . . . . . . . . 35		B.3. NIC Chile Labs Implementation . . . . . . . . . . . . . . 35
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
	1. Introduction		1. Introduction
	skipping to change at page 7, line 24 ¶		skipping to change at page 7, line 24 ¶
	server and firewall products. While RPZ zones can be signed with		server and firewall products. While RPZ zones can be signed with
	DNSSEC, the data is not queried directly, and would not be subject to		DNSSEC, the data is not queried directly, and would not be subject to
	DNSSEC validation.		DNSSEC validation.
	1.4.4. Centralized Zone Data Service		1.4.4. Centralized Zone Data Service
	ICANN operates the Centralized Zone Data Service [CZDS], which is a		ICANN operates the Centralized Zone Data Service [CZDS], which is a
	repository of top-level domain zone files. Users that have been		repository of top-level domain zone files. Users that have been
	granted access are then able to download zone data. Adding a zone		granted access are then able to download zone data. Adding a zone
	digest to these would provide CZDS users with assurances that the		digest to these would provide CZDS users with assurances that the
	data has not been modified. ZONEMD could be added to CZDS zone data		data has not been modified between origination and retrieval. ZONEMD
	independently of the zone served by production name servers.		could be added to CZDS zone data independently of the zone served by
			production name servers.
	1.4.5. General Purpose Comparison Check		1.4.5. General Purpose Comparison Check
	Since the zone digest calculation does not depend on presentation		Since the zone digest calculation does not depend on presentation
	format, it could be used to compare multiple copies of a zone		format, it could be used to compare multiple copies of a zone
	received from different sources, or copies generated by different		received from different sources, or copies generated by different
	processes.		processes.
	1.5. Terminology		1.5. Terminology
	skipping to change at page 9, line 24 ¶		skipping to change at page 9, line 28 ¶
	Scheme values 240-254 are allocated for Private Use.		Scheme values 240-254 are allocated for Private Use.
	2.2.3. The Hash Algorithm Field		2.2.3. The Hash Algorithm Field
	The Hash Algorithm field is an 8-bit unsigned integer that identifies		The Hash Algorithm field is an 8-bit unsigned integer that identifies
	the cryptographic hash algorithm used to construct the digest.		the cryptographic hash algorithm used to construct the digest.
	Herein, SHA384 [RFC6234], with value 1, is the only standardized Hash		Herein, SHA384 [RFC6234], with value 1, is the only standardized Hash
	Algorithm defined for ZONEMD records that MUST be implemented. When		Algorithm defined for ZONEMD records that MUST be implemented. When
	SHA384 is used, the size of the Digest field is 48 octets.		SHA384 is used, the size of the Digest field is 48 octets. The
			result of the SHA384 digest algorithm MUST NOT be truncated, and the
			entire 48 octet digest is published in the ZONEMD record.
	SHA512 [RFC6234], with Hash Algorithm value 2, is also defined for		SHA512 [RFC6234], with Hash Algorithm value 2, is also defined for
	ZONEMD records, and SHOULD be implemented. When SHA512 is used, the		ZONEMD records, and SHOULD be implemented. When SHA512 is used, the
	size of the Digest field is 64 octets.		size of the Digest field is 64 octets. The result of the SHA512
			digest algorithm MUST NOT be truncated, and the entire 64 octet
			digest is published in the ZONEMD record.
	Hash Algorithm values 240-254 are allocated for Private Use.		Hash Algorithm values 240-254 are allocated for Private Use.
	The Hash Algorithm registry is further described in Section 5.		The Hash Algorithm registry is further described in Section 5.
	2.2.4. The Digest Field		2.2.4. The Digest Field
	The Digest field is a variable-length sequence of octets containing		The Digest field is a variable-length sequence of octets containing
	the output of the hash algorithm. The Digest field MUST NOT be		the output of the hash algorithm. The length of the Digest field is
	shorter than 12 octets. The length of the Digest field is determined		determined by deducting the fixed size of the Serial, Scheme, and
	by deducting the fixed size of the Serial, Scheme, and Hash Algorithm		Hash Algorithm fields from the RDATA size in the ZONEMD RR header.
	fields from the RDATA size in the ZONEMD RR header. Section 3
	describes how to calculate the digest for a zone. Section 4		The Digest field MUST NOT be shorter than 12 octets. Digests for the
	describes how to use the digest to verify the contents of a zone.		SHA384 and SHA512 hash algorithms specified herein are never
			truncated. Digests for future hash algorithms MAY be truncated, but
			MUST NOT be truncated to a length that results in less than 96-bits
			(12 octets) of equivalent strength.
			Section 3 describes how to calculate the digest for a zone.
			Section 4 describes how to use the digest to verify the contents of a
			zone.
	2.3. ZONEMD Presentation Format		2.3. ZONEMD Presentation Format
	The presentation format of the RDATA portion is as follows:		The presentation format of the RDATA portion is as follows:
	The Serial field is represented as an unsigned decimal integer.		The Serial field is represented as an unsigned decimal integer.
	The Scheme field is represented as an unsigned decimal integer.		The Scheme field is represented as an unsigned decimal integer.
	The Hash Algorithm field is represented as an unsigned decimal		The Hash Algorithm field is represented as an unsigned decimal
	skipping to change at page 10, line 40 ¶		skipping to change at page 11, line 6 ¶
	created correctly if the zone is signed with DNSSEC. If placeholders		created correctly if the zone is signed with DNSSEC. If placeholders
	were not added prior to signing, the later addition of ZONEMD records		were not added prior to signing, the later addition of ZONEMD records
	would also require updating the Type Bit Maps field of any apex NSEC/		would also require updating the Type Bit Maps field of any apex NSEC/
	NSEC3 RRs, which then invalidates the calculated digest value.		NSEC3 RRs, which then invalidates the calculated digest value.
	When multiple ZONEMD RRs are published in the zone, e.g., during an		When multiple ZONEMD RRs are published in the zone, e.g., during an
	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.		the SOA. However, the TTL of the ZONEMD record may be safely ignored
			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 ZONEMD records are excluded from
	digest calculation, the value of the Digest field does not matter at		digest calculation, the value of the Digest field does not matter at
	this point in the process.		this point in the process.
	3.2. Optionally Sign the Zone		3.2. Optionally Sign the Zone
	skipping to change at page 18, line 18 ¶		skipping to change at page 18, line 40 ¶
	9. Acknowledgments		9. Acknowledgments
	The authors wish to thank David Blacka, Scott Hollenbeck, and Rick		The authors wish to thank David Blacka, Scott Hollenbeck, and Rick
	Wilhelm for providing feedback on early drafts of this document.		Wilhelm for providing feedback on early drafts of this document.
	Additionally, they thank Joe Abley, Mark Andrews, Ralph Dolmans,		Additionally, they thank Joe Abley, Mark Andrews, Ralph Dolmans,
	Donald Eastlake, Richard Gibson, Olafur Gudmundsson, Bob Harold, Paul		Donald Eastlake, Richard Gibson, Olafur Gudmundsson, Bob Harold, Paul
	Hoffman, Evan Hunt, Shumon Huque, Tatuya Jinmei, Mike St. Johns, Burt		Hoffman, Evan Hunt, Shumon Huque, Tatuya Jinmei, Mike St. Johns, Burt
	Kaliski, Shane Kerr, Matt Larson, Barry Leiba, John Levine, Ed Lewis,		Kaliski, Shane Kerr, Matt Larson, Barry Leiba, John Levine, Ed Lewis,
	Matt Pounsett, Mukund Sivaraman, Petr Spacek, Ondrej Sury, Willem		Matt Pounsett, Mukund Sivaraman, Petr Spacek, Ondrej Sury, Willem
	Toorop, Florian Weimer, Tim Wicinksi, Wouter Wijngarrds, Paul		Toorop, Florian Weimer, Tim Wicinski, Wouter Wijngaards, Paul
	Wouters, and other members of the dnsop working group for their		Wouters, and other members of the DNS working group for their input.
	input.
	10. Change Log		10. Change Log
	RFC Editor: Please remove this section before publication.		RFC Editor: Please remove this section before publication.
	This section lists substantial changes to the document as it is being		This section lists substantial changes to the document as it is being
	worked on.		worked on.
	From -00 to -01:		From -00 to -01:
	skipping to change at page 24, line 8 ¶		skipping to change at page 24, line 28 ¶
	o From SECDIR review, say that ZONEMD RRs MAY be ignored by local		o From SECDIR review, say that ZONEMD RRs MAY be ignored by local
	policy.		policy.
	o Moved Implementation Status to an appendix with the intention to		o Moved Implementation Status to an appendix with the intention to
	retain it in RFC.		retain it in RFC.
	o In registry tables, changed Status column to Implementation		o In registry tables, changed Status column to Implementation
	Requirement.		Requirement.
			From -10 to -11:
			o Fixed people's names in the acknowledgments section (blush)
			o Say "has not been modified between origination and retrieval."
			o Say that ZONEMD TTL doesn't matter during verification.
			o Further clarification that the SHA-384 and SHA-512 hashes are not
			truncated. Future algs might be truncated, but never below 96
			bits.
	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. 16 change blocks.
	26 lines changed or deleted		50 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/