idnits 2.17.1 draft-vandijk-dnsop-ds-digest-verbatim-00.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 (25 September 2020) is 1281 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 25 September 2020 5 Expires: 29 March 2021 7 The VERBATIM Digest Algorithm for DS records 8 draft-vandijk-dnsop-ds-digest-verbatim-00 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 29 March 2021. 32 Copyright Notice 34 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . 3 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 58 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 4 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 61 9. Normative References . . . . . . . . . . . . . . . . . . . . 4 62 10. Informative References . . . . . . . . . . . . . . . . . . . 4 63 Appendix A. Document history . . . . . . . . . . . . . . . . . . 4 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 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?'. For several imagined use cases for 78 signed data at the parent, this might not be sufficient. 80 This document introduces a new Digest Algorithm, proposed name 81 VERBATIM (alternative suggestion: NULL). The VERBATIM Digest 82 Algorithm takes the input data (DNSKEY owner name | DNSKEY RDATA per 83 section 5.1.4 of [RFC4034]) and copies it unmodified into the DS 84 Digest field. 86 2. Document work 88 This document lives on GitHub (https://github.com/PowerDNS/draft- 89 dnsop-ds-digest-verbatim); proposed text and editorial changes are 90 very much welcomed there, but any functional changes should always 91 first be discussed on the IETF DNSOP WG mailing list. 93 3. Conventions and Definitions 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in BCP 98 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 4. Implementation 103 The subsection titles in this section attempt to follow the 104 terminology from [RFC8499] in as far as it has suitable terms. 105 'Implementation' is understood to mean both 'code changes' and 106 'operational changes' here. 108 4.1. Authoritative server changes 110 None, except where related tooling emits DS records to the 111 administrator. 113 4.2. Validating resolver changes 115 Validating resolvers are encouraged to implement the VERBATIM Digest 116 Algorithm. 118 4.3. Stub resolver changes 120 This specification defines no changes to query processing in stub 121 resolvers. 123 4.4. Zone validator changes 125 Zone validators are encouraged to recognise the VERBATIM Digest 126 Algorithm and, where possible, verify it against the child zone's 127 DNSKEY, if it has any for the given algorithm. 129 4.5. Domain registry changes 131 Domain registries are encouraged to allow VERBATIM digests at their 132 user's request. However, a likely outcome is that domain registries 133 will only allow the VERBATIM digest for DNSSEC algorithms whose 134 specifications call for use of the VERBATIM digest. 136 5. Security Considerations 138 FIXME 140 6. Implementation Status 142 [RFC Editor: please remove this section before publication] 144 7. IANA Considerations 146 This document updates the IANA registry "Delegation Signer (DS) 147 Resource Record (RR) Type Digest Algorithms" at 148 https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml 149 (https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml) 151 The following entry is added to the registry: 153 +--------------+----------------+ 154 | Value | TBD | 155 | Description | VERBATIM | 156 | Status | OPTIONAL | 157 | Reference | RFC TBD2 | 158 +--------------+----------------+ 160 8. Acknowledgements 162 9. Normative References 164 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 165 Rose, "Resource Records for the DNS Security Extensions", 166 RFC 4034, DOI 10.17487/RFC4034, March 2005, 167 . 169 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 170 Requirement Levels", BCP 14, RFC 2119, 171 DOI 10.17487/RFC2119, March 1997, 172 . 174 10. Informative References 176 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 177 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 178 May 2017, . 180 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 181 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 182 January 2019, . 184 Appendix A. Document history 186 Author's Address 187 Peter van Dijk 188 PowerDNS 189 Den Haag 190 Netherlands 192 Email: peter.van.dijk@powerdns.com