--- 1/draft-ietf-dnsop-algorithm-update-06.txt 2019-03-13 09:13:17.616002472 -0700 +++ 2/draft-ietf-dnsop-algorithm-update-07.txt 2019-03-13 09:13:17.644003153 -0700 @@ -1,82 +1,82 @@ dnsop P. Wouters Internet-Draft Red Hat Obsoletes: 6944 (if approved) O. Sury Intended status: Standards Track Internet Systems Consortium -Expires: August 21, 2019 February 17, 2019 +Expires: September 13, 2019 March 12, 2019 Algorithm Implementation Requirements and Usage Guidance for DNSSEC - draft-ietf-dnsop-algorithm-update-06 + draft-ietf-dnsop-algorithm-update-07 Abstract The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of non- existence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for DNSSEC. This document obsoletes [RFC6944]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- - Drafts is at https://datatracker.ietf.org/drafts/current/. + Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 21, 2019. + This Internet-Draft will expire on September 13, 2019. Copyright Notice Copyright (c) 2019 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 - (https://trustee.ietf.org/license-info) in effect on the date of + (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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Updating Algorithm Implementation Requirements and Usage Guidance . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3 1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 4 3.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 4 3.2. DNSKEY Algorithm Recommendation . . . . . . . . . . . . . 6 3.3. DS and CDS Algorithms . . . . . . . . . . . . . . . . . . 6 3.4. DS and CDS Algorithm Recommendation . . . . . . . . . . . 7 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 - 5. Operational Considerations . . . . . . . . . . . . . . . . . 7 - 6. Implementation Report . . . . . . . . . . . . . . . . . . . . 8 - 6.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 8 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 + 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 + 4.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 7 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 6. Operational Considerations . . . . . . . . . . . . . . . . . 8 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The DNSSEC signing algorithms are defined by various RFCs, including [RFC4034], [RFC5155], [RFC5702], [RFC5933], [RFC6605], [RFC8080]. DNSSEC is used to provide authentication of data. To ensure @@ -289,21 +289,72 @@ DNSSEC use case requiring 384-bit security strength to arise, SHA-384 is provided for such applications and it MAY be used for generating DS and CDS records in these cases. 3.4. DS and CDS Algorithm Recommendation Operation recommendation for new and existing deployments. The SHA-256 is RECOMMENDED DS and CDS algorithm. -4. Security Considerations +4. Implementation Status + + [RFC Editor Note: Please remove this entire seciton plus all + references to [RFC7942] prior to publication as an RFC.] + + This section records the status of known implementations of the + protocol defined by this specification at the time of posting of this + Internet-Draft, and is based on a proposal described in [RFC7942]. + The description of implementations in this section is intended to + assist the IETF in its decision processes in progressing drafts to + RFCs. Please note that the listing of any individual implementation + here does not imply endorsement by the IETF. Furthermore, no effort + has been spent to verify the information presented here that was + supplied by IETF contributors. This is not intended as, and must not + be construed to be, a catalog of available implementations or their + features. Readers are advised to note that other implementations may + exist. + + According to RFC 7942, "this will allow reviewers and working groups + to assign due consideration to documents that have the benefit of + running code, which may serve as evidence of valuable experimentation + and feedback that have made the implemented protocols more mature. + It is up to the individual working groups to use this information as + they see fit". + +4.1. DNSKEY Algorithms + + The following table contains the status of support in the open-source + DNS signers and validators in the current released versions as of the + time writing this document. Usually, the support for specific + algorithm has to be also included in the cryptographic libraries that + the software use. + + +--------------------+------+--------+---------+----------+---------+ + | Mnemonics | BIND | Knot | OpenDNS | PowerDNS | Unbound | + | | | DNS | | | | + +--------------------+------+--------+---------+----------+---------+ + | RSAMD5 | Y | N | Y | N | N | + | DSA | Y | N | Y | N | Y | + | RSASHA1 | Y | Y | Y | Y | Y | + | DSA-NSEC3-SHA1 | Y | N | Y | N | Y | + | RSASHA1-NSEC3-SHA1 | Y | Y | Y | Y | Y | + | RSASHA256 | Y | Y | Y | Y | Y | + | RSASHA512 | Y | Y | Y | Y | Y | + | ECC-GOST | N | N | Y | N | Y | + | ECDSAP256SHA256 | Y | Y | Y | Y | Y | + | ECDSAP384SHA384 | Y | Y | Y | Y | Y | + | ED25519 | Y | Y | N | Y | Y | + | ED448 | N | N | N | Y | Y | + +--------------------+------+--------+---------+----------+---------+ + +5. Security Considerations The security of cryptographic systems depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering of the protocol used by the system to ensure that there are no non- cryptographic ways to bypass the security of the overall system. This document concerns itself with the selection of cryptographic algorithms for the use of DNSSEC, specifically with the selection of "mandatory-to-implement" algorithms. The algorithms identified in @@ -312,59 +363,31 @@ us to believe that they are likely to remain secure into the foreseeable future. However, this isn't necessarily forever, and it is expected that new revisions of this document will be issued from time to time to reflect the current best practices in this area. Retiring an algorithm too soon would result in a zone signed with the retired algorithm being downgraded to the equivalent of an unsigned zone. Therefore, algorithm deprecation must be done very slowly and only after careful consideration and measurement of its use. -5. Operational Considerations +6. Operational Considerations DNSKEY algorithm rollover in a live zone is a complex process. See [RFC6781] and [RFC7583] for guidelines on how to perform algorithm rollovers. DS algorithm rollover in a live zone is also a complex process. Upgrading algorithm at the same time as rolling the new KSK key will lead to DNSSEC validation failures, and users MUST upgrade the DS algorithm first before rolling the Key Signing Key. -6. Implementation Report - -6.1. DNSKEY Algorithms - - The following table contains the status of support in the open-source - DNS signers and validators in the current released versions as of the - time writing this document. Usually, the support for specific - algorithm has to be also included in the cryptographic libraries that - the software use. - - +--------------------+------+--------+---------+----------+---------+ - | Mnemonics | BIND | Knot | OpenDNS | PowerDNS | Unbound | - | | | DNS | | | | - +--------------------+------+--------+---------+----------+---------+ - | RSAMD5 | Y | N | Y | N | N | - | DSA | Y | N | Y | N | Y | - | RSASHA1 | Y | Y | Y | Y | Y | - | DSA-NSEC3-SHA1 | Y | N | Y | N | Y | - | RSASHA1-NSEC3-SHA1 | Y | Y | Y | Y | Y | - | RSASHA256 | Y | Y | Y | Y | Y | - | RSASHA512 | Y | Y | Y | Y | Y | - | ECC-GOST | N | N | Y | Y | Y | - | ECDSAP256SHA256 | Y | Y | Y | Y | Y | - | ECDSAP384SHA384 | Y | Y | Y | Y | Y | - | ED25519 | Y | Y | N | Y | Y | - | ED448 | N | N | N | Y | Y | - +--------------------+------+--------+---------+----------+---------+ - 7. IANA Considerations This document makes no requests of IANA. 8. Acknowledgements This document borrows text from RFC 4307 by Jeffrey I. Schiller of the Massachusetts Institute of Technology (MIT) and the 4307bis document by Yoav Nir, Tero Kivinen, Paul Wouters and Daniel Migault. Much of the original text has been copied verbatim. @@ -374,102 +397,107 @@ Kudos to Roy Arends for bringing the DS rollover issue to the daylight. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . + DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, . [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, - DOI 10.17487/RFC5702, October 2009, - . + DOI 10.17487/RFC5702, October 2009, . [RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July 2010, . [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC", RFC 6605, - DOI 10.17487/RFC6605, April 2012, - . + DOI 10.17487/RFC6605, April 2012, . [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, - DOI 10.17487/RFC6781, December 2012, - . + DOI 10.17487/RFC6781, December 2012, . [RFC6944] Rose, S., "Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status", RFC 6944, - DOI 10.17487/RFC6944, April 2013, - . + DOI 10.17487/RFC6944, April 2013, . [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013, . [RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: Hash Function", RFC 6986, DOI 10.17487/RFC6986, August 2013, . [RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012: Digital Signature Algorithm", RFC 7091, - DOI 10.17487/RFC7091, December 2013, - . + DOI 10.17487/RFC7091, December 2013, . [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating DNSSEC Delegation Trust Maintenance", RFC 7344, - DOI 10.17487/RFC7344, September 2014, - . + DOI 10.17487/RFC7344, September 2014, . [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, "DNSSEC Key Rollover Timing Considerations", RFC 7583, - DOI 10.17487/RFC7583, October 2015, - . + DOI 10.17487/RFC7583, October 2015, . + + [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running + Code: The Implementation Status Section", BCP 205, + RFC 7942, DOI 10.17487/RFC7942, July 2016, + . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, - DOI 10.17487/RFC8032, January 2017, - . + DOI 10.17487/RFC8032, January 2017, . [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from the Parent via CDS/CDNSKEY", RFC 8078, - DOI 10.17487/RFC8078, March 2017, - . + DOI 10.17487/RFC8078, March 2017, . [RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC", RFC 8080, - DOI 10.17487/RFC8080, February 2017, - . + DOI 10.17487/RFC8080, February 2017, . [DNSKEY-IANA] "DNSKEY Algorithms", . [DS-IANA] "Delegation Signer Digest Algorithms", . Authors' Addresses