--- 1/draft-ietf-dnsop-algorithm-update-02.txt 2018-10-23 11:13:07.366321897 -0700 +++ 2/draft-ietf-dnsop-algorithm-update-03.txt 2018-10-23 11:13:07.390322478 -0700 @@ -1,19 +1,19 @@ dnsop P. Wouters Internet-Draft Red Hat Obsoletes: 6944 (if approved) O. Sury Intended status: Standards Track Internet Systems Consortium -Expires: April 17, 2019 October 14, 2018 +Expires: April 26, 2019 October 23, 2018 Algorithm Implementation Requirements and Usage Guidance for DNSSEC - draft-ietf-dnsop-algorithm-update-02 + draft-ietf-dnsop-algorithm-update-03 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 @@ -27,21 +27,21 @@ 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/. 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 April 17, 2019. + This Internet-Draft will expire on April 26, 2019. Copyright Notice Copyright (c) 2018 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 publication of this document. Please review these documents @@ -56,28 +56,29 @@ 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 . . . . . . . . . . . . . . . . . . . . 7 - 6.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 7 + 6.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 interoperability, a set of "mandatory-to-implement" DNSKEY algorithms are defined. This document obsoletes [RFC6944]. @@ -236,22 +237,23 @@ cryptography is less prone to implementation errors ([RFC8032], [RFC8080]). It is expected that ED25519 will become the future RECOMMENDED default algorithm once there's enough support for this algorithm in the deployed DNSSEC validators. 3.2. DNSKEY Algorithm Recommendation Operation recommendation for new and existing deployments. Due to industry-wide trend to move to elliptic curve cryptography, - the ECDSAP256SHA256 is RECOMMENDED for use by new DNSSEC deployments, - and users of RSA based algorithms SHOULD upgrade to ECDSAP256SHA256. + the ECDSAP256SHA256 is RECOMMENDED DNSKEY algorithm for use by new + DNSSEC deployments, and users of RSA based algorithms SHOULD upgrade + to ECDSAP256SHA256. 3.3. DS and CDS Algorithms Recommendations for Delegation Signer Digest Algorithms [DNSKEY-IANA] These also apply to the CDS RRTYPE as specified in [RFC7344] +--------+-----------------+-------------------+-------------------+ | Number | Mnemonics | DNSSEC Delegation | DNSSEC Validation | +--------+-----------------+-------------------+-------------------+ | 0 | NULL (CDS only) | MUST NOT [*] | MUST NOT [*] | @@ -277,20 +279,26 @@ SHA-384 shares the same properties as SHA-256, but offers a modest security advantage over SHA-384 (384-bits of strength versus 256-bits). For most applications of DNSSEC, SHA-256 should be satisfactory and robust for the foreseeable future, and is therefore recommended for DS and CDS records. While it is unlikely for a 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 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 @@ -312,27 +320,27 @@ 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 minimal version of the software that - implements the required functionality. Usually, the support for - specific algorithm has to be also included in the cryptographic - libraries that the DNS servers use. + 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 |