< draft-vandijk-dnsop-ds-digest-verbatim-00.txt		draft-vandijk-dnsop-ds-digest-verbatim-01.txt >
	dnsop P. van Dijk		dnsop P. van Dijk
	Internet-Draft PowerDNS		Internet-Draft PowerDNS
	Intended status: Standards Track 25 September 2020		Intended status: Standards Track 10 August 2021
	Expires: 29 March 2021		Expires: 11 February 2022
	The VERBATIM Digest Algorithm for DS records		The VERBATIM Digest Algorithm for DS records
	draft-vandijk-dnsop-ds-digest-verbatim-00		draft-vandijk-dnsop-ds-digest-verbatim-01
	Abstract		Abstract
	The VERBATIM DS Digest is defined as a direct copy of the input data		The VERBATIM DS Digest is defined as a direct copy of the input data
	without any hashing.		without any hashing.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 31 ¶		skipping to change at page 1, line 31 ¶
	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 29 March 2021.		This Internet-Draft will expire on 11 February 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Document work . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Document work . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Conventions and Definitions . . . . . . . . . . . . . . . . . 3		3. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
	4. Implementation . . . . . . . . . . . . . . . . . . . . . . . 3		4. Implementation . . . . . . . . . . . . . . . . . . . . . . . 3
	4.1. Authoritative server changes . . . . . . . . . . . . . . 3		4.1. Authoritative server changes . . . . . . . . . . . . . . 3
	4.2. Validating resolver changes . . . . . . . . . . . . . . . 3		4.2. Validating resolver changes . . . . . . . . . . . . . . . 3
	4.3. Stub resolver changes . . . . . . . . . . . . . . . . . . 3		4.3. Stub resolver changes . . . . . . . . . . . . . . . . . . 3
	4.4. Zone validator changes . . . . . . . . . . . . . . . . . 3		4.4. Zone validator changes . . . . . . . . . . . . . . . . . 3
	4.5. Domain registry changes . . . . . . . . . . . . . . . . . 3		4.5. Domain registry changes . . . . . . . . . . . . . . . . . 4
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 3		5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
	6. Implementation Status . . . . . . . . . . . . . . . . . . . . 4		6. Implementation Status . . . . . . . . . . . . . . . . . . . . 4
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
	9. Normative References . . . . . . . . . . . . . . . . . . . . 4		9. Normative References . . . . . . . . . . . . . . . . . . . . 4
	10. Informative References . . . . . . . . . . . . . . . . . . . 4		10. Informative References . . . . . . . . . . . . . . . . . . . 5
	Appendix A. Document history . . . . . . . . . . . . . . . . . . 4		Appendix A. Document history . . . . . . . . . . . . . . . . . . 5
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
	1. Introduction		1. Introduction
	The currently defined DS Digest Algorithms take the input data and		The currently defined DS Digest Algorithms take the input data and
	hash it into a fixed-length form using well defined hashing		hash it into a fixed-length form using well defined hashing
	algorithms (several SHA variants, and one mostly unused GOST		algorithms (several SHA variants, and one mostly unused GOST
	algorithm). That hashing operation makes any data inside the		algorithm). That hashing operation makes any data inside the
	(C)DNSKEY record unreachable until that data is retrieved from the		(C)DNSKEY record unreachable until that data is retrieved from the
	child zone. Thus, DS records do not actually convey information;		child zone. Thus, DS records do not actually convey information;
	they merely verify information that can be retrieved elsewhere.		they merely verify information that can be retrieved elsewhere.
	A DS record set can only answer the question 'this data that I have		A DS record set can only answer the question 'this data that I have
	here, do you recognise it?'. For several imagined use cases for		here, do you recognise it?'. In that sense, DS records are not
	signed data at the parent, this might not be sufficient.		information sources - they are boolean oracles. For several imagined
			use cases for signed data at the parent, this might not be
			sufficient. One such use case is https://datatracker.ietf.org/doc/
			draft-schwartz-ds-glue/ (https://datatracker.ietf.org/doc/draft-
			schwartz-ds-glue/) [FIXME: make this a proper ref].
	This document introduces a new Digest Algorithm, proposed name		This document introduces a new Digest Algorithm, proposed name
	VERBATIM (alternative suggestion: NULL). The VERBATIM Digest		VERBATIM (alternative suggestion: NULL). The VERBATIM Digest
	Algorithm takes the input data (DNSKEY owner name | DNSKEY RDATA per		Algorithm takes the input data (DNSKEY owner name | DNSKEY RDATA per
	section 5.1.4 of [RFC4034]) and copies it unmodified into the DS		section 5.1.4 of [RFC4034]) and copies it unmodified into the DS
	Digest field.		Digest field.
	2. Document work		2. Document work
	This document lives on GitHub (https://github.com/PowerDNS/draft-		This document lives on GitHub (https://github.com/PowerDNS/draft-
	skipping to change at page 3, line 50 ¶		skipping to change at page 4, line 14 ¶
	4.5. Domain registry changes		4.5. Domain registry changes
	Domain registries are encouraged to allow VERBATIM digests at their		Domain registries are encouraged to allow VERBATIM digests at their
	user's request. However, a likely outcome is that domain registries		user's request. However, a likely outcome is that domain registries
	will only allow the VERBATIM digest for DNSSEC algorithms whose		will only allow the VERBATIM digest for DNSSEC algorithms whose
	specifications call for use of the VERBATIM digest.		specifications call for use of the VERBATIM digest.
	5. Security Considerations		5. Security Considerations
	FIXME		Previously existing DS Digest Algorithms have a fixed size output.
			The VERBATIM digest has a variable size output, that may be under the
			control of a third party, like the owner of a delegated domain. Such
			a third party might cause zone files to grow very big with just a few
			data submissions to a registrar/registry. DNS query responses
			containing VERBATIM digests might also be bigger than is desired.
			Implementors, specifically domain registries, may want to limit use
			of VERBATIM to specified use cases, and with limits appropriate to
			those use cases.
	6. Implementation Status		6. Implementation Status
	[RFC Editor: please remove this section before publication]		[RFC Editor: please remove this section before publication]
	7. IANA Considerations		7. IANA Considerations
	This document updates the IANA registry "Delegation Signer (DS)		This document updates the IANA registry "Delegation Signer (DS)
	Resource Record (RR) Type Digest Algorithms" at		Resource Record (RR) Type Digest Algorithms" at
	https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml		https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml
	skipping to change at page 4, line 29 ¶		skipping to change at page 4, line 49 ¶
	| Value | TBD |		| Value | TBD |
	| Description | VERBATIM |		| Description | VERBATIM |
	| Status | OPTIONAL |		| Status | OPTIONAL |
	| Reference | RFC TBD2 |		| Reference | RFC TBD2 |
	+--------------+----------------+		+--------------+----------------+
	8. Acknowledgements		8. Acknowledgements
	9. Normative References		9. Normative References
	[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Resource Records for the DNS Security Extensions",
	RFC 4034, DOI 10.17487/RFC4034, March 2005,
	<https://www.rfc-editor.org/info/rfc4034>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
			[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
			Rose, "Resource Records for the DNS Security Extensions",
			RFC 4034, DOI 10.17487/RFC4034, March 2005,
			<https://www.rfc-editor.org/info/rfc4034>.
	10. Informative References		10. Informative References
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS		[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,		Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
	January 2019, <https://www.rfc-editor.org/info/rfc8499>.		January 2019, <https://www.rfc-editor.org/info/rfc8499>.
End of changes. 11 change blocks.
	19 lines changed or deleted		32 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/