idnits 2.17.1 draft-ietf-dnsop-dnssec-iana-cons-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 104: '... [DS-IANA] registries that are not mentioned in this document MAY be...' RFC 2119 keyword, line 106: '... specified as MAY in this document o...' RFC 2119 keyword, line 107: '... from a MUST or a RECOMMENDED to a M...' RFC 2119 keyword, line 115: '... not mentioned in this document MAY be...' RFC 2119 keyword, line 117: '... specified as MAY in this document o...' (1 more instance...) -- The draft header indicates that this document updates RFC3658, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3658, updated by this document, for RFC5378 checks: 2001-05-30) -- 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 (July 21, 2021) is 1008 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 114, but not defined == Missing Reference: 'DS-IANA' is mentioned on line 114, but not defined -- Obsolete informational reference (is this intentional?): RFC 3658 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 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: 3658, 5155, 6014, 8624 (if July 21, 2021 5 approved) 6 Intended status: Standards Track 7 Expires: January 22, 2022 9 Revised IANA Considerations for DNSSEC 10 draft-ietf-dnsop-dnssec-iana-cons-01 12 Abstract 14 This document changes the review requirements needed to get some 15 DNSSEC algorithms and resource records added to IANA registries. It 16 updates RFC 6014 to include hash algorithms for DS records and NSEC3 17 parameters. It also updates RFC 5155 and RFC 6014, which have 18 requirements for DNSSEC algorithms. It also updates RFC 8624 to say 19 that algorithms that are described in RFCs that are not on standards 20 track are only at the "MAY" level of implementation recommendation. 21 The 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 January 22, 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 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Update to RFC 6014 . . . . . . . . . . . . . . . . . . . . . 2 61 3. Update to RFC 8624 . . . . . . . . . . . . . . . . . . . . . 3 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 66 6.2. Informative References . . . . . . . . . . . . . . . . . 4 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 DNSSEC is primarily described in [RFC4033], [RFC4034], and [RFC4035]. 72 DNSSEC commonly uses two resource records beyond those defined in RFC 73 4034: DS [RFC3658] and NSEC3 [RFC5155]. 75 [RFC8126] describes the requirements for listing in the myriad IANA 76 registries. 78 [RFC6014] updated the requirements for how DNSSEC cryptographic 79 algorithm identifiers in the IANA registries are allocated, reducing 80 the requirements from being "Standards Action" to "RFC Required". 81 However, the IANA registry requirements for hash algorithms for DS 82 records and for the hash algorithms used in NSEC3 are still 83 "Standards Action". 85 2. Update to RFC 6014 87 Section 4 updates RFC 6014 to bring the requirements for DS records 88 and NSEC3 hash algorithms in line with the rest of the DNSSEC 89 cryptographic algorithms by allowing any DS or NSEC3 hash algorithms 90 that are fully described in an RFC to have identifiers allocated in 91 the IANA registries. This is an addition to the IANA considerations 92 in RFC 6014. 94 3. Update to RFC 8624 96 This document updates [RFC8624] for all DNSKEY and DS algorithms that 97 are not on standards track. 99 The second paragraph of Section 1.2 of RFC 8624 currently says: 101 This document only provides recommendations with respect to 102 mandatory-to-implement algorithms or algorithms so weak that they 103 cannot be recommended. Any algorithm listed in the [DNSKEY-IANA] and 104 [DS-IANA] registries that are not mentioned in this document MAY be 105 implemented. For clarification and consistency, an algorithm will be 106 specified as MAY in this document only when it has been downgraded 107 from a MUST or a RECOMMENDED to a MAY. 109 That paragraph is now replaced with the following: 111 This document provides recommendations with respect to mandatory-to- 112 implement algorithms, algorithms so weak that they cannot be 113 recommended, and algorithms that are defined in RFCs that are not on 114 standards track. Any algorithm listed in the [DNSKEY-IANA] and [DS- 115 IANA] registries that are not mentioned in this document MAY be 116 implemented. For clarification and consistency, an algorithm will be 117 specified as MAY in this document only when it has been downgraded 118 from a MUST or a RECOMMENDED to a MAY. 120 This update is also reflected in the IANA considerations in 121 Section 4. 123 4. IANA Considerations 125 In the "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3) 126 Parameters" registry, the registration procedure for "DNSSEC NSEC3 127 Flags", "DNSSEC NSEC3 Hash Algorithms", and "DNSSEC NSEC3PARAM Flags" 128 are changed from "Standards Action" to "RFC Required". 130 In the "Delegation Signer (DS) Resource Record (RR) Type Digest 131 Algorithms" registry, the registration procedure for "Digest 132 Algorithms" is changed from "Standards Action" to "RFC Required". 134 5. Security Considerations 136 Changing the requirements for getting security algorithms added to 137 IANA registries as described in this document will make it easier to 138 get good algorithms added to the registries, and will make it easier 139 to get bad algorithms added to the registries. It is impossible to 140 weigh the security impact of those two changes. 142 6. References 144 6.1. Normative References 146 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 147 Rose, "DNS Security Introduction and Requirements", 148 RFC 4033, DOI 10.17487/RFC4033, March 2005, 149 . 151 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 152 Rose, "Resource Records for the DNS Security Extensions", 153 RFC 4034, DOI 10.17487/RFC4034, March 2005, 154 . 156 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 157 Rose, "Protocol Modifications for the DNS Security 158 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 159 . 161 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 162 Security (DNSSEC) Hashed Authenticated Denial of 163 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 164 . 166 [RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier 167 Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014, 168 November 2010, . 170 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 171 Writing an IANA Considerations Section in RFCs", BCP 26, 172 RFC 8126, DOI 10.17487/RFC8126, June 2017, 173 . 175 [RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation 176 Requirements and Usage Guidance for DNSSEC", RFC 8624, 177 DOI 10.17487/RFC8624, June 2019, 178 . 180 6.2. Informative References 182 [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record 183 (RR)", RFC 3658, DOI 10.17487/RFC3658, December 2003, 184 . 186 Author's Address 188 Paul Hoffman 189 ICANN 191 Email: paul.hoffman@icann.org