draft-ietf-dnsop-algorithm-update-02.txt   draft-ietf-dnsop-algorithm-update-03.txt 
dnsop P. Wouters dnsop P. Wouters
Internet-Draft Red Hat Internet-Draft Red Hat
Obsoletes: 6944 (if approved) O. Sury Obsoletes: 6944 (if approved) O. Sury
Intended status: Standards Track Internet Systems Consortium 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 Algorithm Implementation Requirements and Usage Guidance for DNSSEC
draft-ietf-dnsop-algorithm-update-02 draft-ietf-dnsop-algorithm-update-03
Abstract Abstract
The DNSSEC protocol makes use of various cryptographic algorithms in The DNSSEC protocol makes use of various cryptographic algorithms in
order to provide authentication of DNS data and proof of non- order to provide authentication of DNS data and proof of non-
existence. To ensure interoperability between DNS resolvers and DNS existence. To ensure interoperability between DNS resolvers and DNS
authoritative servers, it is necessary to specify a set of algorithm authoritative servers, it is necessary to specify a set of algorithm
implementation requirements and usage guidelines to ensure that there implementation requirements and usage guidelines to ensure that there
is at least one algorithm that all implementations support. This is at least one algorithm that all implementations support. This
document defines the current algorithm implementation requirements document defines the current algorithm implementation requirements
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Updating Algorithm Implementation Requirements and Usage 1.1. Updating Algorithm Implementation Requirements and Usage
Guidance . . . . . . . . . . . . . . . . . . . . . . . . 2 Guidance . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3 1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3
1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4 1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 4 3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 4
3.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 4 3.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 4
3.2. DNSKEY Algorithm Recommendation . . . . . . . . . . . . . 6 3.2. DNSKEY Algorithm Recommendation . . . . . . . . . . . . . 6
3.3. DS and CDS Algorithms . . . . . . . . . . . . . . . . . . 6 3.3. DS and CDS Algorithms . . . . . . . . . . . . . . . . . . 6
3.4. DS and CDS Algorithm Recommendation . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. Operational Considerations . . . . . . . . . . . . . . . . . 7 5. Operational Considerations . . . . . . . . . . . . . . . . . 7
6. Implementation Report . . . . . . . . . . . . . . . . . . . . 7 6. Implementation Report . . . . . . . . . . . . . . . . . . . . 7
6.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 7 6.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The DNSSEC signing algorithms are defined by various RFCs, including The DNSSEC signing algorithms are defined by various RFCs, including
[RFC4034], [RFC5155], [RFC5702], [RFC5933], [RFC6605], [RFC8080]. [RFC4034], [RFC5155], [RFC5702], [RFC5933], [RFC6605], [RFC8080].
DNSSEC is used to provide authentication of data. To ensure DNSSEC is used to provide authentication of data. To ensure
interoperability, a set of "mandatory-to-implement" DNSKEY algorithms interoperability, a set of "mandatory-to-implement" DNSKEY algorithms
are defined. This document obsoletes [RFC6944]. are defined. This document obsoletes [RFC6944].
skipping to change at page 6, line 12 skipping to change at page 6, line 12
cryptography is less prone to implementation errors ([RFC8032], cryptography is less prone to implementation errors ([RFC8032],
[RFC8080]). It is expected that ED25519 will become the future [RFC8080]). It is expected that ED25519 will become the future
RECOMMENDED default algorithm once there's enough support for this RECOMMENDED default algorithm once there's enough support for this
algorithm in the deployed DNSSEC validators. algorithm in the deployed DNSSEC validators.
3.2. DNSKEY Algorithm Recommendation 3.2. DNSKEY Algorithm Recommendation
Operation recommendation for new and existing deployments. Operation recommendation for new and existing deployments.
Due to industry-wide trend to move to elliptic curve cryptography, Due to industry-wide trend to move to elliptic curve cryptography,
the ECDSAP256SHA256 is RECOMMENDED for use by new DNSSEC deployments, the ECDSAP256SHA256 is RECOMMENDED DNSKEY algorithm for use by new
and users of RSA based algorithms SHOULD upgrade to ECDSAP256SHA256. DNSSEC deployments, and users of RSA based algorithms SHOULD upgrade
to ECDSAP256SHA256.
3.3. DS and CDS Algorithms 3.3. DS and CDS Algorithms
Recommendations for Delegation Signer Digest Algorithms [DNSKEY-IANA] Recommendations for Delegation Signer Digest Algorithms [DNSKEY-IANA]
These also apply to the CDS RRTYPE as specified in [RFC7344] These also apply to the CDS RRTYPE as specified in [RFC7344]
+--------+-----------------+-------------------+-------------------+ +--------+-----------------+-------------------+-------------------+
| Number | Mnemonics | DNSSEC Delegation | DNSSEC Validation | | Number | Mnemonics | DNSSEC Delegation | DNSSEC Validation |
+--------+-----------------+-------------------+-------------------+ +--------+-----------------+-------------------+-------------------+
| 0 | NULL (CDS only) | MUST NOT [*] | MUST NOT [*] | | 0 | NULL (CDS only) | MUST NOT [*] | MUST NOT [*] |
skipping to change at page 7, line 5 skipping to change at page 7, line 7
SHA-384 shares the same properties as SHA-256, but offers a modest SHA-384 shares the same properties as SHA-256, but offers a modest
security advantage over SHA-384 (384-bits of strength versus security advantage over SHA-384 (384-bits of strength versus
256-bits). For most applications of DNSSEC, SHA-256 should be 256-bits). For most applications of DNSSEC, SHA-256 should be
satisfactory and robust for the foreseeable future, and is therefore satisfactory and robust for the foreseeable future, and is therefore
recommended for DS and CDS records. While it is unlikely for a recommended for DS and CDS records. While it is unlikely for a
DNSSEC use case requiring 384-bit security strength to arise, SHA-384 DNSSEC use case requiring 384-bit security strength to arise, SHA-384
is provided for such applications and it MAY be used for generating is provided for such applications and it MAY be used for generating
DS and CDS records in these cases. 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. Security Considerations
The security of cryptographic systems depends on both the strength of The security of cryptographic systems depends on both the strength of
the cryptographic algorithms chosen and the strength of the keys used the cryptographic algorithms chosen and the strength of the keys used
with those algorithms. The security also depends on the engineering with those algorithms. The security also depends on the engineering
of the protocol used by the system to ensure that there are no non- of the protocol used by the system to ensure that there are no non-
cryptographic ways to bypass the security of the overall system. cryptographic ways to bypass the security of the overall system.
This document concerns itself with the selection of cryptographic This document concerns itself with the selection of cryptographic
algorithms for the use of DNSSEC, specifically with the selection of algorithms for the use of DNSSEC, specifically with the selection of
skipping to change at page 7, line 40 skipping to change at page 8, line 4
DNSKEY algorithm rollover in a live zone is a complex process. See DNSKEY algorithm rollover in a live zone is a complex process. See
[RFC6781] and [RFC7583] for guidelines on how to perform algorithm [RFC6781] and [RFC7583] for guidelines on how to perform algorithm
rollovers. rollovers.
DS algorithm rollover in a live zone is also a complex process. 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 Upgrading algorithm at the same time as rolling the new KSK key will
lead to DNSSEC validation failures, and users MUST upgrade the DS lead to DNSSEC validation failures, and users MUST upgrade the DS
algorithm first before rolling the Key Signing Key. algorithm first before rolling the Key Signing Key.
6. Implementation Report 6. Implementation Report
6.1. DNSKEY Algorithms 6.1. DNSKEY Algorithms
The following table contains minimal version of the software that The following table contains the status of support in the open-source
implements the required functionality. Usually, the support for DNS signers and validators in the current released versions as of the
specific algorithm has to be also included in the cryptographic time writing this document. Usually, the support for specific
libraries that the DNS servers use. algorithm has to be also included in the cryptographic libraries that
the software use.
+--------------------+------+--------+---------+----------+---------+ +--------------------+------+--------+---------+----------+---------+
| Mnemonics | BIND | Knot | OpenDNS | PowerDNS | Unbound | | Mnemonics | BIND | Knot | OpenDNS | PowerDNS | Unbound |
| | | DNS | | | | | | | DNS | | | |
+--------------------+------+--------+---------+----------+---------+ +--------------------+------+--------+---------+----------+---------+
| RSAMD5 | Y | N | Y | N | N | | RSAMD5 | Y | N | Y | N | N |
| DSA | Y | N | Y | N | Y | | DSA | Y | N | Y | N | Y |
| RSASHA1 | Y | Y | Y | Y | Y | | RSASHA1 | Y | Y | Y | Y | Y |
| DSA-NSEC3-SHA1 | Y | N | Y | N | Y | | DSA-NSEC3-SHA1 | Y | N | Y | N | Y |
| RSASHA1-NSEC3-SHA1 | Y | Y | Y | Y | Y | | RSASHA1-NSEC3-SHA1 | Y | Y | Y | Y | Y |
 End of changes. 10 change blocks. 
12 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/