idnits 2.17.1 draft-arends-dnsop-dnssec-algorithm-update-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 (March 12, 2017) is 2594 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP R. Arends 3 Internet-Draft ICANN 4 Intended status: Standards Track J. Schlyter 5 Expires: September 13, 2017 Kirei AB 6 M. Larson 7 ICANN 8 March 12, 2017 10 DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates 11 draft-arends-dnsop-dnssec-algorithm-update-00 13 Abstract 15 The DNS Security Extensions (DNSSEC) require the use of cryptographic 16 algorithm suites for generating digital signatures and cryptographic 17 hashes over DNS data. The algorithms specified for use with DNSSEC 18 are reflected in IANA registries. This document updates some entries 19 in these registries. The main reason for these updates is to retire 20 the use of SHA1. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 13, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . 2 58 2. The DNS Security Algorithm Implementation Status Lists . . . 2 59 2.1. Status Definitions . . . . . . . . . . . . . . . . . . . 2 60 2.2. Algorithm Implementation Status Assignment Rationale . . 3 61 2.3. DNSSEC Implementation Status Table . . . . . . . . . . . 3 62 2.4. Specifying New Algorithms and Updating the Status of 63 Existing Entries . . . . . . . . . . . . . . . . . . . . 4 64 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 66 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 68 5.2. Informative References . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 The Domain Name System (DNS) Security Extensions (DNSSEC, defined by 74 [RFC4033], [RFC4034], [RFC4035], [RFC4509], [RFC5155], and [RFC5702]) 75 use digital signatures over DNS data to provide source authentication 76 and integrity protection. DNSSEC uses IANA registries to list codes 77 for digital signature algorithms and hash functions. 79 This document updates a set of entries in the IANA registries titled 80 "DNS Security (DNSSEC) Algorithm Numbers" and "Delegation Signer (DS) 81 Resource Record (RR) Type Digest Algorithms". 83 1.1. Reserved Words 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 2. The DNS Security Algorithm Implementation Status Lists 91 2.1. Status Definitions 93 Must Implement: The algorithm MUST be implemented to interoperate 94 with other implementations of this specification. 96 Must Not Implement: The algorithm MUST NOT be implemented. An 97 algorithm with this status has known weaknesses. 99 Recommended to Implement: The algorithm SHOULD be implemented. 100 Utility and interoperability with other implementations will be 101 improved when an algorithm with this status is implemented, though 102 there might be occasions where it is reasonable not to implement the 103 algorithm. An implementer must understand and weigh the full 104 implications of choosing not to implement this particular algorithm. 106 Optional: The algorithm MAY be implemented, but all implementations 107 MUST be prepared to interoperate with implementations that do or do 108 not implement this algorithm. 110 2.2. Algorithm Implementation Status Assignment Rationale 112 RSASHA1 had an implementation status of "Must Implement", consistent 113 with [RFC4034]. The status of RSASHA1 is set to "Recommended to 114 Implement" consistent with RSASHA1-NSEC3-SHA1. The shift from "Must 115 Implement" to "Recommended to Implement" is due to a perceived 116 weakness in SHA1. 118 The status of RSASHA256 is set to "Must Implement" as major 119 deployments, such as the root zone [RZDPS], use these algorithms. It 120 is believed that RSA/SHA-256 or RSA/SHA-512 algorithms will replace 121 older algorithms (e.g., RSA/SHA-1) that have a perceived weakness. 123 All other algorithms used in DNSSEC specified without an 124 implementation status are currently set to "Optional". 126 2.3. DNSSEC Implementation Status Table 128 The DNSSEC algorithm implementation status table is listed below. 129 Only the algorithms already specified for use with DNSSEC at the time 130 of writing are listed. 132 +-----------+-----------+--------------------+----------------------+ 133 | Must | Must Not | Recommended | Optional | 134 | Implement | Implement | | | 135 +-----------+-----------+--------------------+----------------------+ 136 | RSASHA256 | RSAMD5 | RSASHA1 | Any registered | 137 | | | | algorithm not listed | 138 | | | | in this table | 139 | | | RSASHA1-NSEC3-SHA1 | | 140 | | | RSASHA512 | | 141 | | | ECDSAP256SHA256 | | 142 | | | ECDSAP384SHA384 | | 143 +-----------+-----------+--------------------+----------------------+ 144 This table does not list the Reserved values in the IANA registry 145 table or the values for INDIRECT (252), PRIVATE (253), and PRIVATEOID 146 (254). These values may relate to more than one algorithm and are 147 therefore up to the implementer's discretion. As noted, any 148 algorithm not listed in the table is "Optional". 150 2.4. Specifying New Algorithms and Updating the Status of Existing 151 Entries 153 [RFC6014] establishes a parallel procedure for adding a registry 154 entry for a new algorithm other than a standards track document. 155 Because any algorithm not listed in the foregoing table is 156 "Optional", algorithms entered into the registry using the [RFC6014] 157 procedure are automatically "Optional". 159 It has turned out to be useful for implementations to refer to a 160 single document that specifies the implementation status of every 161 algorithm. Accordingly, when a new algorithm is to be registered 162 with a status other than "Optional", this document shall be made 163 obsolete by a new document that adds the new algorithm to the table 164 in Section 2.3. Similarly, if the status of any algorithm in the 165 table in Section 2.3 changes, a new document shall make this document 166 obsolete; that document shall include a replacement of the table in 167 Section 2.3. This way, the goal of having one authoritative document 168 to specify all the status values is achieved. 170 This document cannot be updated, only made obsolete and replaced by a 171 successor document. 173 3. IANA Considerations 175 This document lists the implementation status of cryptographic 176 algorithms used with DNSSEC. These algorithms are maintained in an 177 IANA registry at . Because this document establishes the implementation 179 status of every algorithm, it has been listed as a reference for the 180 registry itself. 182 4. Security Considerations 184 This document lists, and in some cases assigns, the implementation 185 status of cryptographic algorithms used with DNSSEC. It is not meant 186 to be a discussion on algorithm superiority. 188 Since the status of two algorithms have changed, it is important to 189 consider the long term effect of these changes in implementations. 191 An implementation may have provided a default algorithm to use when 192 generating a DNSKEY. An implementation may select a default 193 algorithm to sign DNSSEC records. It is recommended that 194 implementations that provide a default algorithm use an algorithm 195 with the status "Must Implement". 197 5. References 199 5.1. Normative References 201 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 202 Requirement Levels", BCP 14, RFC 2119, 203 DOI 10.17487/RFC2119, March 1997, 204 . 206 5.2. Informative References 208 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 209 Rose, "DNS Security Introduction and Requirements", 210 RFC 4033, DOI 10.17487/RFC4033, March 2005, 211 . 213 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 214 Rose, "Resource Records for the DNS Security Extensions", 215 RFC 4034, DOI 10.17487/RFC4034, March 2005, 216 . 218 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 219 Rose, "Protocol Modifications for the DNS Security 220 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 221 . 223 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 224 (DS) Resource Records (RRs)", RFC 4509, 225 DOI 10.17487/RFC4509, May 2006, 226 . 228 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 229 Security (DNSSEC) Hashed Authenticated Denial of 230 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 231 . 233 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 234 and RRSIG Resource Records for DNSSEC", RFC 5702, 235 DOI 10.17487/RFC5702, October 2009, 236 . 238 [RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier 239 Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014, 240 November 2010, . 242 [RZDPS] Ljunggren, F., Okubo, T., Lamb, R., and J. Schlyter, 243 "DNSSEC Practice Statement for the Root Zone KSK 244 Operator", October 2010, . 247 Authors' Addresses 249 Roy Arends 250 ICANN 252 Email: roy.arends@icann.org 254 Jakob Schlyter 255 Kirei AB 257 Email: jakob@kirei.se 259 Matt Larson 260 ICANN 262 Email: matt.larson@icann.org