draft-ietf-dnsop-algorithm-update-08.txt   draft-ietf-dnsop-algorithm-update-09.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: October 11, 2019 April 9, 2019 Expires: October 12, 2019 April 10, 2019
Algorithm Implementation Requirements and Usage Guidance for DNSSEC Algorithm Implementation Requirements and Usage Guidance for DNSSEC
draft-ietf-dnsop-algorithm-update-08 draft-ietf-dnsop-algorithm-update-09
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
and usage guidance for DNSSEC. This document obsoletes [RFC6944]. and usage guidance for DNSSEC. This document obsoletes RFC6944.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 11, 2019. This Internet-Draft will expire on October 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 5, line 15 skipping to change at page 5, line 15
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.
RSASHA1 does not support NSEC3. RSASHA1-NSEC3-SHA1 can be used with RSASHA1 does not support NSEC3. RSASHA1-NSEC3-SHA1 can be used with
or without NSEC3. or without NSEC3.
DSA and DSA-NSEC3-SHA1 are not widely deployed and vulnerable to DSA and DSA-NSEC3-SHA1 are not widely deployed and vulnerable to
private key compromise when generating signatures using a weak or private key compromise when generating signatures using a weak or
compromised random number generator. compromised random number generator.
RSASHA256 is in wide use and considered strong. RSASHA256 is in wide use and considered strong. It has been the
default algorithm for a number of years and is now slowly being
replaced with ECDSAP256SHA256 due to its shorter key and signature
size, resulting in smaller DNS packets.
RSASHA512 is NOT RECOMMENDED for DNSSEC Signing because it has not RSASHA512 is NOT RECOMMENDED for DNSSEC Signing because it has not
seen wide deployment, but there are some deployments hence DNSSEC seen wide deployment, but there are some deployments hence DNSSEC
Validation MUST implement RSASHA512 to ensure interoperability. Validation MUST implement RSASHA512 to ensure interoperability.
There is no significant difference in cryptographic strength between There is no significant difference in cryptographic strength between
RSASHA512 and RSASHA256, therefore it is discouraged to use RSASHA512 and RSASHA256, therefore it is discouraged to use
RSASHA512, as it will only make deprecation of older algorithms RSASHA512, as it will only make deprecation of older algorithms
harder. People who wish to use a cryptographically stronger harder. People who wish to use a cryptographically stronger
algorithm should switch to elliptic curve cryptography algorithms. algorithm should switch to elliptic curve cryptography algorithms.
skipping to change at page 6, line 9 skipping to change at page 6, line 12
require the use of a unique random number for each signature, there require the use of a unique random number for each signature, there
are no padding or truncation issues as with ECDSA, and it is more are no padding or truncation issues as with ECDSA, and it is more
resilient to side-channel attacks. Furthermore, EdDSA cryptography resilient to side-channel attacks. Furthermore, EdDSA cryptography
is less prone to implementation errors ([RFC8032], [RFC8080]). It is is less prone to implementation errors ([RFC8032], [RFC8080]). It is
expected that ED25519 will become the future RECOMMENDED default expected that ED25519 will become the future RECOMMENDED default
algorithm once there's enough support for this algorithm in the algorithm once there's enough support for this algorithm in the
deployed DNSSEC validators. deployed DNSSEC validators.
3.2. DNSKEY Algorithm Recommendation 3.2. DNSKEY Algorithm Recommendation
Operational recommendation for new and existing deployments.
Due to the industry-wide trend towards elliptic curve cryptography, Due to the industry-wide trend towards elliptic curve cryptography,
ECDSAP256SHA256 is the RECOMMENDED DNSKEY algorithm for use by new ECDSAP256SHA256 is the RECOMMENDED DNSKEY algorithm for use by new
DNSSEC deployments, and users of RSA-based algorithms SHOULD upgrade DNSSEC deployments, and users of RSA-based algorithms SHOULD upgrade
to ECDSAP256SHA256. 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 recommendations also apply to the CDS RRTYPE as specified in These recommendations also apply to the CDS RRTYPE as specified in
[RFC7344] [RFC7344]
skipping to change at page 7, line 16 skipping to change at page 7, line 17
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 3.4. DS and CDS Algorithm Recommendation
Operation recommendation for new and existing deployments: SHA-256 is Operation recommendation for new and existing deployments: SHA-256 is
the RECOMMENDED DS and CDS algorithm. the RECOMMENDED DS and CDS algorithm.
4. Implementation Status 4. Implementation Status
[RFC Editor Note: Please remove this entire seciton plus all [RFC Editor Note: Please remove this entire section plus all
references to [RFC7942] prior to publication as an RFC.] references to [RFC7942] prior to publication as an RFC.]
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was has been spent to verify the information presented here that was
skipping to change at page 8, line 32 skipping to change at page 8, line 32
5. Security Considerations 5. 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 use in DNSSEC, specifically with the selection of
"mandatory-to-implement" algorithms. The algorithms identified in "mandatory-to-implement" algorithms. The algorithms identified in
this document as MUST or RECOMMENDED to implement are not known to be this document as MUST or RECOMMENDED to implement are not known to be
broken (in the cryptographic sense) at the current time, and broken (in the cryptographic sense) at the current time, and
cryptographic research so far leads us to believe that they are cryptographic research so far leads us to believe that they are
likely to remain secure into the foreseeable future. However, this likely to remain secure into the foreseeable future. However, this
isn't necessarily forever, and it is expected that new revisions of 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 this document will be issued from time to time to reflect the current
best practices in this area. best practices in this area.
Retiring an algorithm too soon would result in a zone signed with the Retiring an algorithm too soon would result in a zone signed with the
 End of changes. 8 change blocks. 
9 lines changed or deleted 10 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/