From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6944.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc6944.txt (limited to 'doc/rfc/rfc6944.txt') diff --git a/doc/rfc/rfc6944.txt b/doc/rfc/rfc6944.txt new file mode 100644 index 0000000..50f292e --- /dev/null +++ b/doc/rfc/rfc6944.txt @@ -0,0 +1,395 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Rose +Request for Comments: 6944 NIST +Updates: 2536, 2539, 3110, 4034, 4398, April 2013 + 5155, 5702, 5933 +Category: Standards Track +ISSN: 2070-1721 + + + Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm + Implementation Status + +Abstract + + The DNS Security Extensions (DNSSEC) requires the use of + cryptographic algorithm suites for generating digital signatures over + DNS data. There is currently an IANA registry for these algorithms, + but there is no record of the recommended implementation status of + each algorithm. This document provides an applicability statement on + algorithm implementation status for DNSSEC component software. This + document lists each algorithm's status based on the current + reference. In the case that an algorithm is specified without an + implementation status, this document assigns one. This document + updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6944. + + + + + + + + + + + + + + +Rose Standards Track [Page 1] + +RFC 6944 DNSSEC DNSKEY Algorithm Status April 2013 + + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 + 2. The DNS Security Algorithm Implementation Status Lists . . . . 3 + 2.1. Status Definitions . . . . . . . . . . . . . . . . . . . . 3 + 2.2. Algorithm Implementation Status Assignment Rationale . . . 4 + 2.3. DNSSEC Implementation Status Table . . . . . . . . . . . . 4 + 2.4. Specifying New Algorithms and Updating the Status of + Existing Entries . . . . . . . . . . . . . . . . . . . . . 5 + 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 + 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 + 5.2. Informative References . . . . . . . . . . . . . . . . . . 7 + + + + + + + + + + + + + + + + + + + + + +Rose Standards Track [Page 2] + +RFC 6944 DNSSEC DNSKEY Algorithm Status April 2013 + + +1. Introduction + + The Domain Name System (DNS) Security Extensions (DNSSEC) ([RFC4033], + [RFC4034], [RFC4035], [RFC4509], [RFC5155], and [RFC5702]) uses + digital signatures over DNS data to provide source authentication and + integrity protection. DNSSEC uses an IANA registry to list codes for + digital signature algorithms (consisting of a cryptographic algorithm + and one-way hash function). + + The original list of algorithm status is found in [RFC4034]. Other + DNSSEC RFCs have added new algorithms or changed the status of + algorithms in the registry. However, implementers must read through + all the documents in order to discover which algorithms are + considered wise to implement, which are not, and which algorithms may + become widely used in the future. + + This document defines the current implementation status for all + registered algorithms. If the status of algorithms changes, this + document will be replaced with a new one establishing the new status; + see Section 2.4. + + This document updates the following: [RFC2536], [RFC2539], [RFC3110], + [RFC4034], [RFC4398], [RFC5155], [RFC5702], and [RFC5933]. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. The DNS Security Algorithm Implementation Status Lists + +2.1. Status Definitions + + Must Implement: The algorithm MUST be implemented to interoperate + with other implementations of this specification. + + Must Not Implement: The algorithm MUST NOT be implemented. An + algorithm with this status has known weaknesses. + + Recommended to Implement: The algorithm SHOULD be implemented. + Utility and interoperability with other implementations will be + improved when an algorithm with this status is implemented, though + there might be occasions where it is reasonable not to implement + the algorithm. An implementer must understand and weigh the full + implications of choosing not to implement this particular + algorithm. + + + + +Rose Standards Track [Page 3] + +RFC 6944 DNSSEC DNSKEY Algorithm Status April 2013 + + + Optional: The algorithm MAY be implemented, but all implementations + MUST be prepared to interoperate with implementations that do or + do not implement this algorithm. + +2.2. Algorithm Implementation Status Assignment Rationale + + RSASHA1 has an implementation status of Must Implement, consistent + with [RFC4034]. RSAMD5 has an implementation status of Must Not + Implement because of known weaknesses in MD5. + + The status of RSASHA1-NSEC3-SHA1 is set to Recommended to Implement + as many deployments use NSEC3. The status of RSA/SHA-256 and RSA/ + SHA-512 are also set to Recommended to Implement as major deployments + (such as the root zone) use these algorithms [ROOTDPS]. It is + believed that RSA/SHA-256 or RSA/SHA-512 algorithms will replace + older algorithms (e.g., RSA/SHA-1) that have a perceived weakness. + + Likewise, ECDSA with the two identified curves (ECDSAP256SHA256 and + ECDSAP384SHA384) is an algorithm that may see widespread use due to + the perceived similar level of security offered with smaller key size + compared to the key sizes of algorithms such as RSA. Therefore, + ECDSAP256SHA256 and ECDSAP384SHA384 are Recommended to Implement. + + All other algorithms used in DNSSEC specified without an + implementation status are currently set to Optional. + +2.3. DNSSEC Implementation Status Table + + The DNSSEC algorithm implementation status table is listed below. + Only the algorithms already specified for use with DNSSEC at the time + of writing are listed. + + +------------+------------+-------------------+-------------------+ + | Must | Must Not | Recommended | Optional | + | Implement | Implement | to Implement | | + +------------+------------+-------------------+-------------------+ + | | | | | + | RSASHA1 | RSAMD5 | RSASHA256 | Any | + | | | RSASHA1-NSEC3 | registered | + | | | -SHA1 | algorithm | + | | | RSASHA512 | not listed in | + | | | ECDSAP256SHA256 | this table | + | | | ECDSAP384SHA384 | | + +------------+------------+-------------------+-------------------+ + + + + + + + +Rose Standards Track [Page 4] + +RFC 6944 DNSSEC DNSKEY Algorithm Status April 2013 + + + This table does not list the Reserved values in the IANA registry + table or the values for INDIRECT (252), PRIVATE (253), and PRIVATEOID + (254). These values may relate to more than one algorithm and are + therefore up to the implementer's discretion. As noted, any + algorithm not listed in the table is Optional. As of this writing, + the Optional algorithms are DSASHA1, DH, DSA-NSEC3-SHA1, and GOST- + ECC, but in general, anything not explicitly listed is Optional. + +2.4. Specifying New Algorithms and Updating the Status of Existing + Entries + + [RFC6014] establishes a parallel procedure for adding a registry + entry for a new algorithm other than a standards track document. + Because any algorithm not listed in the foregoing table is Optional, + algorithms entered into the registry using the [RFC6014] procedure + are automatically Optional. + + It has turned out to be useful for implementations to refer to a + single document that specifies the implementation status of every + algorithm. Accordingly, when a new algorithm is to be registered + with a status other than Optional, this document shall be made + obsolete by a new document that adds the new algorithm to the table + in Section 2.3. Similarly, if the status of any algorithm in the + table in Section 2.3 changes, a new document shall make this document + obsolete; that document shall include a replacement of the table in + Section 2.3. This way, the goal of having one authoritative document + to specify all the status values is achieved. + + This document cannot be updated, only made obsolete and replaced by a + successor document. + +3. IANA Considerations + + This document lists the implementation status of cryptographic + algorithms used with DNSSEC. These algorithms are maintained in an + IANA registry at http://www.iana.org/assignments/dns-sec-alg-numbers. + Because this document establishes the implementation status of every + algorithm, it has been listed as a reference for the registry itself. + +4. Security Considerations + + This document lists, and in some cases assigns, the implementation + status of cryptographic algorithms used with DNSSEC. It is not meant + to be a discussion on algorithm superiority. No new security + considerations are raised in this document, though prior description + of algorithms as NOT RECOMMENDED (see [RFC4034]) has been recast as + Must Not Implement. + + + + +Rose Standards Track [Page 5] + +RFC 6944 DNSSEC DNSKEY Algorithm Status April 2013 + + +5. References + +5.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System + (DNS)", RFC 2536, March 1999. + + [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the + Domain Name System (DNS)", RFC 2539, March 1999. + + [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain + Name System (DNS)", RFC 3110, May 2001. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name + System (DNS)", RFC 4398, March 2006. + + [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer + (DS) Resource Records (RRs)", RFC 4509, May 2006. + + [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS + Security (DNSSEC) Hashed Authenticated Denial of + Existence", RFC 5155, March 2008. + + [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY + and RRSIG Resource Records for DNSSEC", RFC 5702, + October 2009. + + [RFC5933] Dolmatov, V., Chuprina, A., and I. Ustinov, "Use of GOST + Signature Algorithms in DNSKEY and RRSIG Resource Records + for DNSSEC", RFC 5933, July 2010. + + [RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier + Allocation for DNSSEC", RFC 6014, November 2010. + + + +Rose Standards Track [Page 6] + +RFC 6944 DNSSEC DNSKEY Algorithm Status April 2013 + + +5.2. Informative References + + [ROOTDPS] Ljunggren, F., Okubo, T., Lamb, R., and J. Schlyter, + "DNSSEC Practice Statement for the Root Zone KSK + Operator", DNS ROOTDPS, May 2010, + . + +Author's Address + + Scott Rose + NIST + 100 Bureau Dr. + Gaithersburg, MD 20899 + USA + + Phone: +1-301-975-8439 + EMail: scottr.nist@gmail.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rose Standards Track [Page 7] + -- cgit v1.2.3