draft-ietf-dnsop-algorithm-update-00.txt   draft-ietf-dnsop-algorithm-update-01.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: September 22, 2018 March 21, 2018 Expires: December 7, 2018 June 5, 2018
Algorithm Implementation Requirements and Usage Guidance for DNSSEC Algorithm Implementation Requirements and Usage Guidance for DNSSEC
draft-ietf-dnsop-algorithm-update-00 draft-ietf-dnsop-algorithm-update-01
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 guidance to ensure that there implementation requirements and usage guidance 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 September 22, 2018. This Internet-Draft will expire on December 7, 2018.
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 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
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 . . . . . . . . . . 2 1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 2
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 . . . . . . . . . . . . . 5 3.2. DNSKEY Algorithm Recommendation . . . . . . . . . . . . . 6
3.3. DS and CDS Algorithms . . . . . . . . . . . . . . . . . . 6 3.3. DS and CDS Algorithms . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. Operational Considerations . . . . . . . . . . . . . . . . . 7 5. Operational Considerations . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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 4, line 40 skipping to change at page 4, line 40
+--------+--------------------+-----------------+-------------------+ +--------+--------------------+-----------------+-------------------+
| 1 | RSAMD5 | MUST NOT | MUST NOT | | 1 | RSAMD5 | MUST NOT | MUST NOT |
| 3 | DSA | MUST NOT | MUST NOT | | 3 | DSA | MUST NOT | MUST NOT |
| 5 | RSASHA1 | NOT RECOMMENDED | MUST | | 5 | RSASHA1 | NOT RECOMMENDED | MUST |
| 6 | DSA-NSEC3-SHA1 | MUST NOT | MUST NOT | | 6 | DSA-NSEC3-SHA1 | MUST NOT | MUST NOT |
| 7 | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | MUST | | 7 | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | MUST |
| 8 | RSASHA256 | MUST | MUST | | 8 | RSASHA256 | MUST | MUST |
| 10 | RSASHA512 | NOT RECOMMENDED | MUST | | 10 | RSASHA512 | NOT RECOMMENDED | MUST |
| 12 | ECC-GOST | MUST NOT | MAY | | 12 | ECC-GOST | MUST NOT | MAY |
| 13 | ECDSAP256SHA256 | MUST | MUST | | 13 | ECDSAP256SHA256 | MUST | MUST |
| 14 | ECDSAP384SHA384 | NOT RECOMMENDED | RECOMMENDED | | 14 | ECDSAP384SHA384 | MAY | RECOMMENDED |
| 15 | ED25519 | RECOMMENDED | RECOMMENDED | | 15 | ED25519 | RECOMMENDED | RECOMMENDED |
| 16 | ED448 | MAY | RECOMMENDED | | 16 | ED448 | MAY | RECOMMENDED |
+--------+--------------------+-----------------+-------------------+ +--------+--------------------+-----------------+-------------------+
RSAMD5 is not widely deployed and there is an industry-wide trend to RSAMD5 is not widely deployed and there is an industry-wide trend to
deprecate MD5 usage. deprecate MD5 usage.
RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although zones RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although zones
deploying it are recommended to switch to ECDSAP256SHA256 as there is deploying it are recommended to switch to ECDSAP256SHA256 as there is
an industry-wide trend to move to elliptic curve cryptography. an industry-wide trend to move to elliptic curve cryptography.
skipping to change at page 5, line 32 skipping to change at page 5, line 32
in DNSSEC. in DNSSEC.
ECDSAP256SHA256 provide more strength for signature size than ECDSAP256SHA256 provide more strength for signature size than
RSASHA256 and RSASHA512 variants. ECDSAP256SHA256 has been widely RSASHA256 and RSASHA512 variants. ECDSAP256SHA256 has been widely
deployed and therefore it is now at MUST level for both validation deployed and therefore it is now at MUST level for both validation
and signing. It is RECOMMENDED to use deterministic digital and signing. It is RECOMMENDED to use deterministic digital
signature generation procedure of the ECDSA ([RFC6979]) when signature generation procedure of the ECDSA ([RFC6979]) when
implementing ECDSAP256SHA256 (and ECDSAP384SHA384). implementing ECDSAP256SHA256 (and ECDSAP384SHA384).
ECDSAP384SHA384 share the same properties as ECDSAP256SHA256, but ECDSAP384SHA384 share the same properties as ECDSAP256SHA256, but
offers only a little advantage over ECDSAP256SHA256 and has not seen offers a modest security advantage over ECDSAP256SHA256 (192-bits of
wide deployment, so the usage of this algorithm is discouraged, strength versus 128-bits). For most applications of DNSSEC,
especially for signing. ECDSAP256SHA256 should be satisfactory and robust for the foreseeable
future, and is therefore recommended for signing. While it is
unlikely for a DNSSEC use case which requires 192-bit security
strength to arise, ECDSA384SHA384 is provided for such applications
and it MAY be used for signing in these cases.
ED25519 and ED448 uses Edwards-curve Digital Security Algorithm ED25519 and ED448 uses Edwards-curve Digital Security Algorithm
(EdDSA). There are three main advantages of the EdDSA algorithm: It (EdDSA). There are three main advantages of the EdDSA algorithm: It
does not require the use of a unique random number for each does not require the use of a unique random number for each
signature, there are no padding or truncation issues as with ECDSA, signature, there are no padding or truncation issues as with ECDSA,
and it is more resilient to side-channel attacks. Furthermore, EdDSA and it is more resilient to side-channel attacks. Furthermore, EdDSA
cryptography is less prone to implementation errors ([RFC8080]). It cryptography is less prone to implementation errors ([RFC8032],
is expected that ED25519 will become the future RECOMMENDED default [RFC8080]). It is expected that ED25519 will become the future
algorithm once there's enough support for this algorithm in the RECOMMENDED default algorithm once there's enough support for this
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 to be used by new DNSSEC the ECDSAP256SHA256 is RECOMMENDED to be used by new DNSSEC
deployments, and users of RSA based algorithms SHOULD upgrade to deployments, and users of RSA based algorithms SHOULD upgrade to
ECDSAP256SHA256. ECDSAP256SHA256.
skipping to change at page 6, line 36 skipping to change at page 6, line 43
SHA-1 is still in wide use for DS records, so validators MUST SHA-1 is still in wide use for DS records, so validators MUST
implement the validation, but it is disallowed to use SHA-1 to implement the validation, but it is disallowed to use SHA-1 to
generate new DS records. (See Operational Considerations for caveats generate new DS records. (See Operational Considerations for caveats
when upgrading from SHA-1 to SHA-256 DS Algorithm.) when upgrading from SHA-1 to SHA-256 DS Algorithm.)
SHA-256 is in wide use and considered strong. SHA-256 is in wide use and considered strong.
GOST R 34.11-94 has been deprecated by [RFC6986]. GOST R 34.11-94 has been deprecated by [RFC6986].
SHA-384 is not in wide use. It is still recommended to be supported SHA-384 share the same properties as SHA-256, but offers a modest
in validators so that adoption can increase. 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/CDS records. While it is unlikely for a DNSSEC
use case which requires 384-bit security strength to arise, SHA-384
is provided for such applications and it MAY be used for generating
DS/CDS records in these cases.
4. Security Considerations 4. Security Considerations
The security of cryptographic-based systems depends on both the The security of cryptographic-based systems depends on both the
strength of the cryptographic algorithms chosen and the strength of strength of the cryptographic algorithms chosen and the strength of
the keys used with those algorithms. The security also depends on the keys used with those algorithms. The security also depends on
the engineering of the protocol used by the system to ensure that the engineering of the protocol used by the system to ensure that
there are no non-cryptographic ways to bypass the security of the there are no non-cryptographic ways to bypass the security of the
overall system. overall system.
skipping to change at page 7, line 37 skipping to change at page 7, line 51
This document makes no requests of IANA. This document makes no requests of IANA.
7. Acknowledgements 7. Acknowledgements
This document borrows text from RFC 4307 by Jeffrey I. Schiller of This document borrows text from RFC 4307 by Jeffrey I. Schiller of
the Massachusetts Institute of Technology (MIT) and the 4307bis the Massachusetts Institute of Technology (MIT) and the 4307bis
document by Yoav Nir, Tero Kivinen, Paul Wouters and Daniel Migault. document by Yoav Nir, Tero Kivinen, Paul Wouters and Daniel Migault.
Much of the original text has been copied verbatim. Much of the original text has been copied verbatim.
We wish to thank Roland van Rijswijk-Deij, Olafur Gudmundsson and We wish to thank Michael Sinatra, Roland van Rijswijk-Deij, Olafur
Paul Hoffman for their imminent feedback. Gudmundsson and Paul Hoffman for their imminent feedback.
Kudos to Roy Arends for bringing the DS rollover issue to the Kudos to Roy Arends for bringing the DS rollover issue to the
daylight. daylight.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 9, line 15 skipping to change at page 9, line 24
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344, DNSSEC Delegation Trust Maintenance", RFC 7344,
DOI 10.17487/RFC7344, September 2014, DOI 10.17487/RFC7344, September 2014,
<https://www.rfc-editor.org/info/rfc7344>. <https://www.rfc-editor.org/info/rfc7344>.
[RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking,
"DNSSEC Key Rollover Timing Considerations", RFC 7583, "DNSSEC Key Rollover Timing Considerations", RFC 7583,
DOI 10.17487/RFC7583, October 2015, DOI 10.17487/RFC7583, October 2015,
<https://www.rfc-editor.org/info/rfc7583>. <https://www.rfc-editor.org/info/rfc7583>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from
the Parent via CDS/CDNSKEY", RFC 8078, the Parent via CDS/CDNSKEY", RFC 8078,
DOI 10.17487/RFC8078, March 2017, DOI 10.17487/RFC8078, March 2017,
<https://www.rfc-editor.org/info/rfc8078>. <https://www.rfc-editor.org/info/rfc8078>.
[RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security [RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security
Algorithm (EdDSA) for DNSSEC", RFC 8080, Algorithm (EdDSA) for DNSSEC", RFC 8080,
DOI 10.17487/RFC8080, February 2017, DOI 10.17487/RFC8080, February 2017,
<https://www.rfc-editor.org/info/rfc8080>. <https://www.rfc-editor.org/info/rfc8080>.
 End of changes. 12 change blocks. 
19 lines changed or deleted 34 lines changed or added

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