idnits 2.17.1 draft-vandijk-dnsop-ds-digest-verbatim-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (10 August 2021) is 988 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop P. van Dijk 3 Internet-Draft PowerDNS 4 Intended status: Standards Track 10 August 2021 5 Expires: 11 February 2022 7 The VERBATIM Digest Algorithm for DS records 8 draft-vandijk-dnsop-ds-digest-verbatim-01 10 Abstract 12 The VERBATIM DS Digest is defined as a direct copy of the input data 13 without any hashing. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on 11 February 2022. 32 Copyright Notice 34 Copyright (c) 2021 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 39 license-info) in effect on the date of publication of this document. 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. Code Components 42 extracted from this document must include Simplified BSD License text 43 as described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Document work . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 51 4. Implementation . . . . . . . . . . . . . . . . . . . . . . . 3 52 4.1. Authoritative server changes . . . . . . . . . . . . . . 3 53 4.2. Validating resolver changes . . . . . . . . . . . . . . . 3 54 4.3. Stub resolver changes . . . . . . . . . . . . . . . . . . 3 55 4.4. Zone validator changes . . . . . . . . . . . . . . . . . 3 56 4.5. Domain registry changes . . . . . . . . . . . . . . . . . 4 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 4 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 61 9. Normative References . . . . . . . . . . . . . . . . . . . . 4 62 10. Informative References . . . . . . . . . . . . . . . . . . . 5 63 Appendix A. Document history . . . . . . . . . . . . . . . . . . 5 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 The currently defined DS Digest Algorithms take the input data and 69 hash it into a fixed-length form using well defined hashing 70 algorithms (several SHA variants, and one mostly unused GOST 71 algorithm). That hashing operation makes any data inside the 72 (C)DNSKEY record unreachable until that data is retrieved from the 73 child zone. Thus, DS records do not actually convey information; 74 they merely verify information that can be retrieved elsewhere. 76 A DS record set can only answer the question 'this data that I have 77 here, do you recognise it?'. In that sense, DS records are not 78 information sources - they are boolean oracles. For several imagined 79 use cases for signed data at the parent, this might not be 80 sufficient. One such use case is https://datatracker.ietf.org/doc/ 81 draft-schwartz-ds-glue/ (https://datatracker.ietf.org/doc/draft- 82 schwartz-ds-glue/) [FIXME: make this a proper ref]. 84 This document introduces a new Digest Algorithm, proposed name 85 VERBATIM (alternative suggestion: NULL). The VERBATIM Digest 86 Algorithm takes the input data (DNSKEY owner name | DNSKEY RDATA per 87 section 5.1.4 of [RFC4034]) and copies it unmodified into the DS 88 Digest field. 90 2. Document work 92 This document lives on GitHub (https://github.com/PowerDNS/draft- 93 dnsop-ds-digest-verbatim); proposed text and editorial changes are 94 very much welcomed there, but any functional changes should always 95 first be discussed on the IETF DNSOP WG mailing list. 97 3. Conventions and Definitions 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14 [RFC2119] [RFC8174] when, and only when, they appear in all 103 capitals, as shown here. 105 4. Implementation 107 The subsection titles in this section attempt to follow the 108 terminology from [RFC8499] in as far as it has suitable terms. 109 'Implementation' is understood to mean both 'code changes' and 110 'operational changes' here. 112 4.1. Authoritative server changes 114 None, except where related tooling emits DS records to the 115 administrator. 117 4.2. Validating resolver changes 119 Validating resolvers are encouraged to implement the VERBATIM Digest 120 Algorithm. 122 4.3. Stub resolver changes 124 This specification defines no changes to query processing in stub 125 resolvers. 127 4.4. Zone validator changes 129 Zone validators are encouraged to recognise the VERBATIM Digest 130 Algorithm and, where possible, verify it against the child zone's 131 DNSKEY, if it has any for the given algorithm. 133 4.5. Domain registry changes 135 Domain registries are encouraged to allow VERBATIM digests at their 136 user's request. However, a likely outcome is that domain registries 137 will only allow the VERBATIM digest for DNSSEC algorithms whose 138 specifications call for use of the VERBATIM digest. 140 5. Security Considerations 142 Previously existing DS Digest Algorithms have a fixed size output. 143 The VERBATIM digest has a variable size output, that may be under the 144 control of a third party, like the owner of a delegated domain. Such 145 a third party might cause zone files to grow very big with just a few 146 data submissions to a registrar/registry. DNS query responses 147 containing VERBATIM digests might also be bigger than is desired. 149 Implementors, specifically domain registries, may want to limit use 150 of VERBATIM to specified use cases, and with limits appropriate to 151 those use cases. 153 6. Implementation Status 155 [RFC Editor: please remove this section before publication] 157 7. IANA Considerations 159 This document updates the IANA registry "Delegation Signer (DS) 160 Resource Record (RR) Type Digest Algorithms" at 161 https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml 162 (https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml) 164 The following entry is added to the registry: 166 +--------------+----------------+ 167 | Value | TBD | 168 | Description | VERBATIM | 169 | Status | OPTIONAL | 170 | Reference | RFC TBD2 | 171 +--------------+----------------+ 173 8. Acknowledgements 175 9. Normative References 177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 178 Requirement Levels", BCP 14, RFC 2119, 179 DOI 10.17487/RFC2119, March 1997, 180 . 182 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 183 Rose, "Resource Records for the DNS Security Extensions", 184 RFC 4034, DOI 10.17487/RFC4034, March 2005, 185 . 187 10. Informative References 189 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 190 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 191 May 2017, . 193 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 194 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 195 January 2019, . 197 Appendix A. Document history 199 Author's Address 201 Peter van Dijk 202 PowerDNS 203 Den Haag 204 Netherlands 206 Email: peter.van.dijk@powerdns.com