idnits 2.17.1 draft-ietf-dnsext-dnssec-registry-fixes-08.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 draft header indicates that this document updates RFC4034, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2539, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3110, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2536, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4398, 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 == Line 164 has weird spacing: '... Zone actio...' (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 (May 26, 2011) is 4690 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 2537 (Obsoleted by RFC 3110) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 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, May 26, 2011 5 5155, 5702, 5933 (if approved) 6 Intended status: Standards Track 7 Expires: November 27, 2011 9 Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA 10 Registry 11 draft-ietf-dnsext-dnssec-registry-fixes-08 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 is incomplete in that it lacks the implementation status of each 19 algorithm. This document provides an applicability statement on 20 algorithm implementation compliance status for DNSSEC 21 implementations. This status is to measure compliance to this RFC 22 only. This document replaces that registry table with a new IANA 23 registry table for Domain Name System Security (DNSSEC) Algorithm 24 Numbers that lists (or assigns) each algorithm's status based on the 25 current reference. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 27, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 64 2. The DNS Security Algorithm Number Sub-registry . . . . . . . . 3 65 2.1. Updates and Additions . . . . . . . . . . . . . . . . . . . 4 66 2.2. Domain Name System (DNS) Security Algorithm Number 67 Registry Table . . . . . . . . . . . . . . . . . . . . . . 5 68 2.3. Specifying New Algorithms and Updating Status of 69 Existing Entries . . . . . . . . . . . . . . . . . . . . . 6 71 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 75 5. Normative 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 replaces the 92 original list with a new table that includes the current compliance 93 status for certain algorithms. 95 This compliance status indication is only to be considered for 96 implementation, not deployment or operations. Operators are free to 97 deploy any digital signature algorithm available in implementations 98 or algorithms chosen by local security policies. This status is to 99 measure compliance to this RFC only. 101 This document replaces the current IANA registry for Domain Name 102 System Security (DNSSEC) Algorithm Numbers with a newly defined 103 registry table. This new table (Section 2.2 below) contains a column 104 that will list the current compliance status of each digital 105 signature algorithm in the registry at the time of writing and 106 assigns status for some algorithms used with DNSSEC that did not have 107 an identified status in their specification. This document updates 108 the following: [RFC2536], [RFC2539], [RFC3110], [RFC4034], [RFC4398], 109 [RFC5155], [RFC5702], and [RFC5933]. 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 2. The DNS Security Algorithm Number Sub-registry 119 The DNS Security Algorithm Number sub-registry (part of the Domain 120 Name System (DNS) Security Number registry) will be replaced with the 121 table below. This table is based on the existing DNS Security 122 Algorithm Number sub-registry and adds a column that contains the 123 current implementation status of the given algorithm. 125 There are additional differences to entries that are described in 126 sub-section 2.1. The overall new registry table is in sub-section 127 2.2. The values for the compliance status were obtained from 128 [RFC4034] with updates for algorithms specified after the original 129 DNSSEC specification. If no status was listed in the original 130 specification, this document assigns one. 132 2.1. Updates and Additions 134 This document updates three entries in the Domain Name System 135 Security (DNSSEC) Algorithm Registry. They are: 137 The description for assignment number 4 is changed to "Reserved until 138 2020". 140 The description for assignment number 9 is changed to "Reserved until 141 2020". 143 The description for assignment number 11 is changed to "Reserved 144 until 2020". 146 Registry entries 13-251 remains Unassigned. 148 The status of RSASHA1-NSEC3-SHA1 is set to RECOMMENDED TO IMPLEMENT. 149 This is due to the fact that RSA/SHA-1 is a MUST IMPLEMENT. The 150 status of RSA/SHA-256 and RSA/SHA-512 are also set to RECOMMENDED TO 151 IMPLEMENT as it is believed that these algorithms will replace an 152 older algorithm (e.g. RSA/SHA-1) that have a perceived weakness in 153 its hash algorithm (SHA-1). 155 2.2. Domain Name System (DNS) Security Algorithm Number Registry Table 157 The Domain Name System (DNS) Security Algorithm Number registry is 158 hereby specified as follows below. The new column is titled 159 "Compliance to RFC TBD" (where TBD will change when published) as the 160 IANA Registry table is not normative. The IANA registry table is 161 only a reflection of the RFC, which is normative. 163 Trans- 164 Zone action Compliance to 165 Number Description Mnemonic Sign Sign RFC TBD1 Reference 166 ------ ----------- ------ ---- ----- ------------ --------- 167 0 Reserved [RFC4398] 168 1 RSA/MD5 RSAMD5 N Y MUST NOT [RFC2537] 169 IMPLEMENT 170 2 Diffie-Hellman DH N Y [RFC2539] 171 3 DSA/SHA-1 DSASHA1 Y Y [RFC2536] 172 4 Reserved until 173 2020 174 5 RSA/SHA-1 RSASHA1 Y Y MUST [RFC3110] 175 IMPLEMENT 176 6 DSA-NSEC3-SHA1 DSA-NSEC3 Y Y [RFC5155] 177 -SHA1 178 7 RSASHA1-NSEC3 RSASHA1- Y Y RECOMMENDED [RFC5155] 179 -SHA1 NSEC3- TO IMPLEMENT 180 SHA1 181 8 RSA/SHA-256 RSASHA256 Y * RECOMMENDED [RFC5702] 182 TO IMPLEMENT 183 9 Reserved until 184 2020 185 10 RSA/SHA-512 RSASHA512 Y * RECOMMENDED [RFC5702] 186 TO IMPLEMENT 187 11 Reserved until 188 2020 189 12 GOST R GOST-ECC Y * [RFC5933] 190 34.10-2001 191 13-251 Unassigned 192 252 Reserved for INDIRECT N N [RFC4034] 193 Indirect keys 194 253 private PRIVATE Y Y [RFC4034] 195 algorithm 196 254 private PRIVATEOID Y Y [RFC4034] 197 algorithm OID 198 255 Reserved 200 Table rows where the compliance column is not filled in are left to 201 the discretion of implementers. Their implementation (or lack 202 thereof) therefore cannot be included when judging compliance to this 203 document. 205 2.3. Specifying New Algorithms and Updating Status of Existing Entries 207 [RFC6014] establishes a parallel procedure for adding a registry 208 entry for a new algorithm other than a standards track document. 209 Algorithms entered into the registry using that procedure do not have 210 a listed compliance status. Specifications that follow this path do 211 not need to obsolete or update this document. 213 Adding a newly specified algorithm to the registry with a compliance 214 status SHALL entail obsolescing this document and replacing the 215 registry table (with the new algorithm entry). Altering the status 216 column value of any existing algorithm in the registry SHALL entail 217 obsoleting this document and replacing the registry table. 219 This document cannot be updated, only made obsolete and replaced by a 220 successor document. 222 3. IANA Considerations 224 This document replaces the Domain Name System (DNS) Security 225 Algorithm Numbers registry. The new registry table is in Section 226 2.2. In the column "Compliance to RFC TBD", "RFC TBD" should be 227 changed to the official RFC when published. 229 The original Domain Name System (DNS) Security Algorithm Number 230 registry is available at 231 http://www.iana.org/assignments/dns-sec-alg-numbers. 233 4. Security Considerations 235 This document replaces the Domain Name System (DNS) Security 236 Algorithm Numbers registry. It is not meant to be a discussion on 237 algorithm superiority. No new security considerations are raised in 238 this document. 240 5. Normative References 242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 243 Requirement Levels", BCP 14, RFC 2119, March 1997. 245 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 246 (DNS)", RFC 2536, March 1999. 248 [RFC2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name 249 System (DNS)", RFC 2537, March 1999. 251 [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the 252 Domain Name System (DNS)", RFC 2539, March 1999. 254 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 255 Name System (DNS)", RFC 3110, May 2001. 257 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 258 Rose, "DNS Security Introduction and Requirements", 259 RFC 4033, March 2005. 261 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 262 Rose, "Resource Records for the DNS Security Extensions", 263 RFC 4034, March 2005. 265 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 266 Rose, "Protocol Modifications for the DNS Security 267 Extensions", RFC 4035, March 2005. 269 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 270 System (DNS)", RFC 4398, March 2006. 272 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 273 (DS) Resource Records (RRs)", RFC 4509, May 2006. 275 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 276 Security (DNSSEC) Hashed Authenticated Denial of 277 Existence", RFC 5155, March 2008. 279 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 280 and RRSIG Resource Records for DNSSEC", RFC 5702, 281 October 2009. 283 [RFC5933] Dolmatov, V., Chuprina, A., and I. Ustinov, "Use of GOST 284 Signature Algorithms in DNSKEY and RRSIG Resource Records 285 for DNSSEC", RFC 5933, July 2010. 287 [RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier 288 Allocation for DNSSEC", RFC 6014, November 2010. 290 Author's Address 292 Scott Rose 293 NIST 294 100 Bureau Dr. 295 Gaithersburg, MD 20899 296 USA 298 Phone: +1-301-975-8439 299 EMail: scottr.nist@gmail.com