idnits 2.17.1 draft-hoffman-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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC5155, but the abstract doesn't seem to mention this, which it should. -- 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 06, 2020) is 1388 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 normative reference: RFC 3658 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 1 error (**), 0 flaws (~~), 2 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: RFC 3658, RFC 5155, RFC 6014 July 06, 2020 5 (if approved) 6 Intended status: Standards Track 7 Expires: January 7, 2021 9 Revised IANA Considerations for DNSSEC 10 draft-hoffman-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. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 7, 2021. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 2 55 3. Security Considerations . . . . . . . . . . . . . . . . . . . 2 56 4. Normative References . . . . . . . . . . . . . . . . . . . . 3 57 Appendix A. Other Options for Requirements Level . . . . . . . . 3 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1. Introduction 62 DNSSEC is primarily described in [RFC4033], [RFC4034], and [RFC4035]. 63 DNSSEC commonly uses two resource records beyond those defined in RFC 64 4034: DS [RFC3658] and NSEC3 [RFC5155]. 66 [RFC8126] describes the requirements for listing in the myriad IANA 67 registries. 69 [RFC6014] updated the requirements for how DNSSEC cryptographic 70 algorithm identifiers in the IANA registries are allocated, reducing 71 the requirements from being "Standards Action" to "RFC Required". 72 However, the IANA registry requirements for hash algorithms for DS 73 records and for the hash algorithms used in NSEC3 are still 74 "Standards Action". This document updates RFC 6014 to bring the 75 requirements for DS records and NSEC3 hash algorithms in line with 76 the rest of the DNSSEC cryptographic algorithms. 78 2. IANA Considerations 80 In the "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3) 81 Parameters" registry, the registration procedure for "DNSSEC NSEC3 82 Flags", "DNSSEC NSEC3 Hash Algorithms", and "DNSSEC NSEC3PARAM Flags" 83 are changed from "Standards Action" to "RFC Required". 85 In the "Delegation Signer (DS) Resource Record (RR) Type Digest 86 Algorithms" registry, the registration procedure for "Digest 87 Algorithms" is changed from "Standards Action" to "RFC Required". 89 3. Security Considerations 91 Changing the requirements for getting security algorithms added to 92 IANA registries as described in this document will make it easier to 93 get good algorithms added to the registries, and will make it easier 94 to get bad algorithms added to the registries. It is impossible to 95 weigh the security impact of those two changes. 97 4. Normative References 99 [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record 100 (RR)", RFC 3658, DOI 10.17487/RFC3658, December 2003, 101 . 103 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 104 Rose, "DNS Security Introduction and Requirements", 105 RFC 4033, DOI 10.17487/RFC4033, March 2005, 106 . 108 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 109 Rose, "Resource Records for the DNS Security Extensions", 110 RFC 4034, DOI 10.17487/RFC4034, March 2005, 111 . 113 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 114 Rose, "Protocol Modifications for the DNS Security 115 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 116 . 118 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 119 Security (DNSSEC) Hashed Authenticated Denial of 120 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 121 . 123 [RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier 124 Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014, 125 November 2010, . 127 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 128 Writing an IANA Considerations Section in RFCs", BCP 26, 129 RFC 8126, DOI 10.17487/RFC8126, June 2017, 130 . 132 Appendix A. Other Options for Requirements Level 134 During an early discussion in the DNSOP Working Group, it was 135 proposed that the requirements for registry allocation for DS 136 resource records be "Specification Required". This would reduce the 137 work required of specification authors, and of the RFC Editor, while 138 still requiring review by an expert reviewer and a long-lived 139 specification. 141 Author's Address 143 Paul Hoffman 144 ICANN 146 Email: paul.hoffman@icann.org