idnits 2.17.1 draft-ietf-dnsop-dnssec-iana-cons-05.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 (Using the creation date from RFC5155, updated by this document, for RFC5378 checks: 2005-01-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (7 October 2021) is 925 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) == Missing Reference: 'DNSKEY-IANA' is mentioned on line 122, but not defined == Missing Reference: 'DS-IANA' is mentioned on line 122, but not defined -- Obsolete informational reference (is this intentional?): RFC 3658 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft ICANN 4 Updates: 5155, 6014, 8624 (if approved) 7 October 2021 5 Intended status: Standards Track 6 Expires: 10 April 2022 8 Revised IANA Considerations for DNSSEC 9 draft-ietf-dnsop-dnssec-iana-cons-05 11 Abstract 13 This document changes the review requirements needed to get DNSSEC 14 algorithms and resource records added to IANA registries. It updates 15 RFC 6014 to include hash algorithms for DS (Delegation Signer) 16 records and NSEC3 (Hashed Authenticated Denial of Existence) 17 parameters. It also updates RFC 5155 and RFC 6014, which have 18 requirements for DNSSEC algorithms, and updates RFC 8624 to say that 19 algorithms that are described in RFCs that are not on standards track 20 are only at the "MAY" level of implementation recommendation. The 21 rationale for these changes is to bring the requirements for DS 22 records and for the hash algorithms used in NSEC3 in line with the 23 requirements for all other DNSSEC algorithms. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 10 April 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Update to RFC 6014 . . . . . . . . . . . . . . . . . . . . . 3 60 3. Update to RFC 8624 . . . . . . . . . . . . . . . . . . . . . 3 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 65 6.2. Informative References . . . . . . . . . . . . . . . . . 5 66 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 DNSSEC is primarily described in [RFC4033], [RFC4034], and [RFC4035]. 72 DNSSEC commonly uses another resource record beyond those defined in 73 RFC 4034: NSEC3 [RFC5155]. DS resrouce records were originally 74 defined in [RFC3658], and that definition was obsoleted by RFC 4034. 76 [RFC6014] updated the requirements for how DNSSEC cryptographic 77 algorithm identifiers in the IANA registries are assigned, reducing 78 the requirements from being "Standards Action" to "RFC Required". 79 However, the IANA registry requirements for hash algorithms for DS 80 records [RFC3658] and for the hash algorithms used in NSEC3 records 81 [RFC5155] are still "Standards Action". This document updates those 82 IANA registry requirements. (For reference on how IANA registries 83 can be updated in general, see [RFC8126].) 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 87 "OPTIONAL" in this document are to be interpreted as described in BCP 88 14 [RFC2119] [RFC8174] when, and only when, they appear in all 89 capitals, as shown here. 91 2. Update to RFC 6014 93 Section 4 updates RFC 6014 to bring the requirements for DS records 94 and NSEC3 hash algorithms in line with the rest of the DNSSEC 95 cryptographic algorithms by allowing any DS hash algorithms, NSEC3 96 hash algorithms, NSEC3 parameters, and NSEC3 flags that are fully 97 described in an RFC to have identifiers assigned in the IANA 98 registries. This is an addition to the IANA considerations in RFC 99 6014. 101 3. Update to RFC 8624 103 This document updates [RFC8624] for all DNSKEY and DS algorithms that 104 are not on standards track. 106 The second paragraph of Section 1.2 of RFC 8624 currently says: 108 This document only provides recommendations with respect to 109 mandatory-to-implement algorithms or algorithms so weak that they 110 cannot be recommended. Any algorithm listed in the [DNSKEY-IANA] 111 and [DS-IANA] registries that are not mentioned in this document 112 MAY be implemented. For clarification and consistency, an 113 algorithm will be specified as MAY in this document only when it 114 has been downgraded from a MUST or a RECOMMENDED to a MAY. 116 That paragraph is now replaced with the following: 118 This document provides recommendations with respect to 119 mandatory-to-implement algorithms, algorithms so weak that they 120 cannot be recommended, and algorithms that are defined in RFCs 121 that are not on standards track. Any algorithm listed in the 122 [DNSKEY-IANA] and [DS-IANA] registries that are not mentioned in 123 this document MAY be implemented. For clarification and 124 consistency, an algorithm will be specified as MAY in this 125 document only when it has been downgraded from a MUST or a 126 RECOMMENDED to a MAY. 128 This update is also reflected in the IANA considerations in 129 Section 4. 131 4. IANA Considerations 133 In the "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3) 134 Parameters" registry, the registration procedure for "DNSSEC NSEC3 135 Flags", "DNSSEC NSEC3 Hash Algorithms", and "DNSSEC NSEC3PARAM Flags" 136 are changed from "Standards Action" to "RFC Required". 138 In the "Delegation Signer (DS) Resource Record (RR) Type Digest 139 Algorithms" registry, the registration procedure for "Digest 140 Algorithms" is changed from "Standards Action" to "RFC Required". 142 5. Security Considerations 144 Changing the requirements for getting security algorithms added to 145 IANA registries as described in this document will make it easier to 146 get good algorithms added to the registries, and will make it easier 147 to get bad algorithms added to the registries. It is impossible to 148 weigh the security impact of those two changes. 150 Administrators of DNSSEC-signed zones, and of validating resolvers, 151 may have been making security decisions based on the contents of the 152 IANA registries. This was a bad idea in the past, and now is an even 153 worse idea because there will be more algorithms in those registries 154 that may not have gone through IETF review. Security decisions about 155 which algorithms are safe and not safe should be made by reading the 156 security literature, not by looking in IANA registries. 158 6. References 160 6.1. Normative References 162 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 163 Requirement Levels", BCP 14, RFC 2119, 164 DOI 10.17487/RFC2119, March 1997, 165 . 167 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 168 Rose, "DNS Security Introduction and Requirements", 169 RFC 4033, DOI 10.17487/RFC4033, March 2005, 170 . 172 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 173 Rose, "Resource Records for the DNS Security Extensions", 174 RFC 4034, DOI 10.17487/RFC4034, March 2005, 175 . 177 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 178 Rose, "Protocol Modifications for the DNS Security 179 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 180 . 182 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 183 Security (DNSSEC) Hashed Authenticated Denial of 184 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 185 . 187 [RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier 188 Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014, 189 November 2010, . 191 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 192 Writing an IANA Considerations Section in RFCs", BCP 26, 193 RFC 8126, DOI 10.17487/RFC8126, June 2017, 194 . 196 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 197 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 198 May 2017, . 200 [RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation 201 Requirements and Usage Guidance for DNSSEC", RFC 8624, 202 DOI 10.17487/RFC8624, June 2019, 203 . 205 6.2. Informative References 207 [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record 208 (RR)", RFC 3658, DOI 10.17487/RFC3658, December 2003, 209 . 211 Appendix A. Acknowledgements 213 Donald Eastlake, Murray Kucherawy, Dan Harkins, Martin Duke, and 214 Benjamin Kaduk contributed to this document. 216 Author's Address 218 Paul Hoffman 219 ICANN 221 Email: paul.hoffman@icann.org