idnits 2.17.00 (12 Aug 2021) /tmp/idnits33169/draft-ietf-dnsext-dnssec-algo-imp-status-03.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 abstract seems to indicate that this document updates RFC5155, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC5702, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2536, updated by this document, for RFC5378 checks: 1997-09-10) (Using the creation date from RFC2539, updated by this document, for RFC5378 checks: 1997-06-02) -- 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 (June 12, 2012) is 3629 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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 (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions Working Group S. Rose 3 Internet-Draft NIST 4 Updates: 2536, 2539, 3110, 4034, 4398, June 12, 2012 5 5155, 5702, 5933 (if approved) 6 Intended status: BCP 7 Expires: December 14, 2012 9 Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm 10 Implementation Status 11 draft-ietf-dnsext-dnssec-algo-imp-status-03 13 Abstract 15 The DNS Security Extensions (DNSSEC) requires the use of 16 cryptographic algorithm suites for generating digital signatures over 17 DNS data. There is currently an IANA registry for these algorithms 18 that lacks the recommended implementation status of each algorithm. 19 This document provides an applicability statement on algorithm 20 implementation status for DNSSEC component software. This document 21 lists each algorithm's status based on the current reference. In the 22 case that an algorithm is specified without an implementation status, 23 this document assigns one. This document updates RFCs 2536, 2539, 24 3110, 4034, 4398, 5155, 5702, and 5933. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 14, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 63 2. The DNS Security Algorithm Implementation Status Lists . . . . 3 64 2.1. Algorithm Implementation Status Assignement Rationale . . . 3 65 2.2. DNSSEC Implementation Status Table . . . . . . . . . . . . 4 66 2.3. Specifying New Algorithms and Updating Status of 67 Existing Entries . . . . . . . . . . . . . . . . . . . . . 4 69 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 73 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 5.1. Normative References . . . . . . . . . . . . . . . . . . . 5 75 5.2. Informative References . . . . . . . . . . . . . . . . . . 6 77 1. Introduction 79 The Domain Name System (DNS) Security Extensions (DNSSEC) [RFC4033], 80 [RFC4034], [RFC4035], [RFC4509], [RFC5155], and [RFC5702] uses 81 digital signatures over DNS data to provide source authentication and 82 integrity protection. DNSSEC uses an IANA registry to list codes for 83 digital signature algorithms (consisting of a cryptographic algorithm 84 and one-way hash function). 86 The original list of algorithm status is found in [RFC4034]. Other 87 DNSSEC RFC's have added new algorithms or changed the status of 88 algorithms in the registry. However, implementers must read through 89 all the documents in order to discover which algorithms are 90 considered wise to implement, which are not, and which algorithms may 91 become widely used in the future. This document includes the current 92 implementation status for certain algorithms. 94 This implementation status indication is only to be considered for 95 implementation, not deployment or operations. Operators are free to 96 deploy any digital signature algorithm available in implementations 97 or algorithms chosen by local security policies. This status is to 98 measure compliance to this document only. 100 This document updates the following: [RFC2536], [RFC2539], [RFC3110], 101 [RFC4034], [RFC4398], [RFC5155], [RFC5702], and [RFC5933]. 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 2. The DNS Security Algorithm Implementation Status Lists 111 2.1. Algorithm Implementation Status Assignement Rationale 113 The status of RSASHA1-NSEC3-SHA1 is set to RECOMMENDED TO IMPLEMENT 114 as many deployments use NSEC3. The status of RSA/SHA-256 and RSA/ 115 SHA-512 are also set to RECOMMENDED TO IMPLEMENT as major deployments 116 (such as the root zone) use these algorithms [ROOTDPS]. It is 117 believed that RSA/SHA-256 or RSA/SHA-512 algorithms will replace 118 older algorithms (e.g. RSA/SHA-1) that have a perceived weakness or 119 these recommended algorithms are seen in major deployments. 121 Likewise, ECDSA with the two identified curves (ECDSAP256SHA256 and 122 ECDSAP384SHA384) are algorithms that may see widespread use due to 123 the precieved similar level of security offered with smaller key size 124 compared to the key sizes of algorithms such as RSA. 126 All other algorithms used in DNSSEC specified without an 127 implementation status are currently set to OPTIONAL. 129 2.2. DNSSEC Implementation Status Table 131 The DNSSEC algorithm implementation status table is listed below. 132 Only the algorithms already specified for use with DNSSEC (at the 133 time of writing) are listed. 135 +------------+------------+-------------------+-------------------+ 136 | MUST | MUST NOT | RECOMMENDED | OPTIONAL | 137 | IMPLEMENT | IMPLEMENT | TO IMPLEMENT | | 138 +------------+------------+-------------------+-------------------+ 139 | | | | | 140 | RSASHA1 | RSAMD5 | RSASHA256 | DSASHA1 | 141 | | | RSASHA1-NSEC3 | DH | 142 | | | -SHA1 | DSA-NSEC3-SHA1 | 143 | | | RSASHA512 | GOST-ECC | 144 | | | ECDSAP256SHA256 | | 145 | | | ECDSAP384SHA384 | | 146 +------------+------------+-------------------+-------------------+ 148 This table does not list the Reserved values in the IANA registry 149 table or the values for INDIRECT (252), PRIVATE (253) and PRIVATEOID 150 (254). These values may relate to more than one algorithm and are 151 therefore up to the implementer's discretion. Their implementation 152 (or lack thereof) therefore cannot be included when judging 153 compliance to this document. 155 2.3. Specifying New Algorithms and Updating Status of Existing Entries 157 [RFC6014] establishes a parallel procedure for adding a registry 158 entry for a new algorithm other than a standards track document. 159 Algorithms entered into the registry using that procedure are to be 160 considered OPTIONAL for implementation purposes. Specifications that 161 follow this path do not need to obsolete or update this document. 163 Adding a newly specified algorithm to the registry with an 164 implementation status other than OPTIONAL SHALL entail making this 165 document obsolete and replacing the table in Section 2.2 (with the 166 new algorithm entry). Altering the status value of any existing 167 algorithm in the registry SHALL entail making this document obsolete 168 and replacing the table in Section 2.2 above. 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 http://www.iana.org/assignments/dns-sec-alg-numbers. 178 There are no changes to the registry in this document. However this 179 document asks to be listed as a reference for the entire registry. 181 4. Security Considerations 183 This document lists, and in some cases assigns, the implementation 184 status of cryptographic algorithms used with DNSSEC. It is not meant 185 to be a discussion on algorithm superiority. No new security 186 considerations are raised in this document. 188 5. References 190 5.1. Normative References 192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 193 Requirement Levels", BCP 14, RFC 2119, March 1997. 195 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 196 (DNS)", RFC 2536, March 1999. 198 [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the 199 Domain Name System (DNS)", RFC 2539, March 1999. 201 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 202 Name System (DNS)", RFC 3110, May 2001. 204 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 205 Rose, "DNS Security Introduction and Requirements", 206 RFC 4033, March 2005. 208 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 209 Rose, "Resource Records for the DNS Security Extensions", 210 RFC 4034, March 2005. 212 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 213 Rose, "Protocol Modifications for the DNS Security 214 Extensions", RFC 4035, March 2005. 216 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 217 System (DNS)", RFC 4398, March 2006. 219 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 220 (DS) Resource Records (RRs)", RFC 4509, May 2006. 222 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 223 Security (DNSSEC) Hashed Authenticated Denial of 224 Existence", RFC 5155, March 2008. 226 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 227 and RRSIG Resource Records for DNSSEC", RFC 5702, 228 October 2009. 230 [RFC5933] Dolmatov, V., Chuprina, A., and I. Ustinov, "Use of GOST 231 Signature Algorithms in DNSKEY and RRSIG Resource Records 232 for DNSSEC", RFC 5933, July 2010. 234 [RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier 235 Allocation for DNSSEC", RFC 6014, November 2010. 237 5.2. Informative References 239 [ROOTDPS] Ljunggren, F., Okubo, T., Lamb, R., and J. Schlyter, 240 "DNSSEC Practice Statement for the Root Zone KSK 241 Operator", DNS ROOTDPS, May 2010, . 245 Author's Address 247 Scott Rose 248 NIST 249 100 Bureau Dr. 250 Gaithersburg, MD 20899 251 USA 253 Phone: +1-301-975-8439 254 EMail: scottr.nist@gmail.com