| < draft-ietf-dnsop-algorithm-update-06.txt | draft-ietf-dnsop-algorithm-update-10.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: August 21, 2019 February 17, 2019 | Expires: October 22, 2019 April 20, 2019 | |||
| Algorithm Implementation Requirements and Usage Guidance for DNSSEC | Algorithm Implementation Requirements and Usage Guidance for DNSSEC | |||
| draft-ietf-dnsop-algorithm-update-06 | draft-ietf-dnsop-algorithm-update-10 | |||
| 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 August 21, 2019. | This Internet-Draft will expire on October 22, 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 2, line 22 ¶ | skipping to change at page 2, line 22 ¶ | |||
| 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 | 3.4. DS and CDS Algorithm Recommendation . . . . . . . . . . . 7 | |||
| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 | |||
| 5. Operational Considerations . . . . . . . . . . . . . . . . . 7 | 4.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 7 | |||
| 6. Implementation Report . . . . . . . . . . . . . . . . . . . . 8 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | |||
| 6.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 8 | 6. Operational Considerations . . . . . . . . . . . . . . . . . 8 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 | |||
| 9.2. Informative References . . . . . . . . . . . . . . . . . 9 | 9.2. Informative References . . . . . . . . . . . . . . . . . 10 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 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]. | |||
| 1.1. Updating Algorithm Implementation Requirements and Usage Guidance | 1.1. Updating Algorithm Implementation Requirements and Usage Guidance | |||
| The field of cryptography evolves continuously. New stronger | The field of cryptography evolves continuously. New, stronger | |||
| algorithms appear and existing algorithms are found to be less secure | algorithms appear and existing algorithms are found to be less secure | |||
| then originally thought. Therefore, algorithm implementation | then originally thought. Attacks previously thought to be | |||
| requirements and usage guidance need to be updated from time to time | computationally infeasible become more accessible as the available | |||
| to reflect the new reality. The choices for algorithms must be | computational resources increase. Therefore, algorithm | |||
| conservative to minimize the risk of algorithm compromise. | implementation requirements and usage guidance need to be updated | |||
| from time to time to reflect the new reality. The choices for | ||||
| algorithms must be conservative to minimize the risk of algorithm | ||||
| compromise. | ||||
| 1.2. Updating Algorithm Requirement Levels | 1.2. Updating Algorithm Requirement Levels | |||
| The mandatory-to-implement algorithm of tomorrow should already be | The mandatory-to-implement algorithm of tomorrow should already be | |||
| available in most implementations of DNSSEC by the time it is made | available in most implementations of DNSSEC by the time it is made | |||
| mandatory. This document attempts to identify and introduce those | mandatory. This document attempts to identify and introduce those | |||
| algorithms for future mandatory-to-implement status. There is no | algorithms for future mandatory-to-implement status. There is no | |||
| guarantee that algorithms in use today will become mandatory in the | guarantee that algorithms in use today will become mandatory in the | |||
| future. Published algorithms are continuously subjected to | future. Published algorithms are continuously subjected to | |||
| cryptographic attack and may become too weak, or even be completely | cryptographic attack and may become too weak, or even be completely | |||
| broken, before this document is updated. | broken, before this document is updated. | |||
| This document only provides recommendations with respect to | This document only provides recommendations with respect to | |||
| mandatory-to-implement algorithms or algorithms so weak that | mandatory-to-implement algorithms or algorithms so weak that these | |||
| recommendation cannot be recommended. Any algorithm listed in the | cannot be recommended. Any algorithm listed in the [DNSKEY-IANA] and | |||
| [DNSKEY-IANA] and [DS-IANA] registries, but not mentioned in this | [DS-IANA] registries, but not mentioned in this document, MAY be | |||
| document, MAY be implemented. For clarification and consistency, an | implemented. For clarification and consistency, an algorithm will be | |||
| algorithm will be specified as MAY in this document only when it has | specified as MAY in this document only when it has been downgraded | |||
| been downgraded. | from a MUST or a RECOMMENDED to a MAY. | |||
| Although this document's primary purpose is to update algorithm | Although this document's primary purpose is to update algorithm | |||
| recommendations to keep DNSSEC authentication secure over time, it | recommendations to keep DNSSEC authentication secure over time, it | |||
| also aims to do so in such a way that DNSSEC implementations remain | also aims to do so in such a way that DNSSEC implementations remain | |||
| interoperable. DNSSEC interoperability is addressed by an | interoperable. DNSSEC interoperability is addressed by an | |||
| incremental introduction or deprecation of algorithms. | incremental introduction or deprecation of algorithms. | |||
| [RFC2119] considers the term SHOULD equivalent to RECOMMENDED, and | [RFC2119] considers the term SHOULD equivalent to RECOMMENDED, and | |||
| SHOULD NOT equivalent to NOT RECOMMENDED. The authors of this | SHOULD NOT equivalent to NOT RECOMMENDED. The authors of this | |||
| document have chosen to use the terms RECOMMENDED and NOT | document have chosen to use the terms RECOMMENDED and NOT | |||
| RECOMMENDED, as this more clearly expresses the recommendations to | RECOMMENDED, as this more clearly expresses the intent to | |||
| implementers. | implementers. | |||
| It is expected that deprecation of an algorithm will be performed | It is expected that deprecation of an algorithm will be performed | |||
| gradually. This provides time for various implementations to update | gradually in a series of updates to this document. This provides | |||
| their implemented algorithms while remaining interoperable. Unless | time for various implementations to update their implemented | |||
| there are strong security reasons, an algorithm is expected to be | algorithms while remaining interoperable. Unless there are strong | |||
| downgraded from MUST to NOT RECOMMENDED or MAY, instead of to MUST | security reasons, an algorithm is expected to be downgraded from MUST | |||
| NOT. Similarly, an algorithm that has not been mentioned as | to NOT RECOMMENDED or MAY, instead of to MUST NOT. Similarly, an | |||
| mandatory-to-implement is expected to be introduced with a | algorithm that has not been mentioned as mandatory-to-implement is | |||
| RECOMMENDED instead of a MUST. | expected to be introduced with a RECOMMENDED instead of a MUST. | |||
| Since the effect of using an unknown DNSKEY algorithm is that the | Since the effect of using an unknown DNSKEY algorithm is that the | |||
| zone is treated as insecure, it is recommended that algorithms | zone is treated as insecure, it is recommended that algorithms | |||
| downgraded to NOT RECOMMENDED or lower not be used by authoritative | downgraded to NOT RECOMMENDED or lower not be used by authoritative | |||
| nameservers and DNSSEC signers to create new DNSKEY's. This will | nameservers and DNSSEC signers to create new DNSKEYs. This will | |||
| allow for deprecated algorithms to become less and less common over | allow for deprecated algorithms to become less and less common over | |||
| time. Once an algorithm has reached a sufficiently low level of | time. Once an algorithm has reached a sufficiently low level of | |||
| deployment, it can be marked as MUST NOT, so that recursive resolvers | deployment, it can be marked as MUST NOT, so that recursive resolvers | |||
| can remove support for validating it. | can remove support for validating it. | |||
| Recursive nameservers are encouraged to retain support for all | Recursive nameservers are encouraged to retain support for all | |||
| algorithms not marked as MUST NOT. | algorithms not marked as MUST NOT. | |||
| 1.3. Document Audience | 1.3. Document Audience | |||
| The recommendations of this document mostly target DNSSEC | The recommendations of this document mostly target DNSSEC | |||
| implementers, as implementations need to meet both high security | implementers, as implementations need to meet both high security | |||
| expectations as well as high interoperability between various vendors | expectations as well as high interoperability between various vendors | |||
| and with different versions. Interoperability requires a smooth | and with different versions. Interoperability requires a smooth | |||
| transition to more secure algorithms. This perspective may differ | transition to more secure algorithms. This perspective may differ | |||
| from from that of a user who wishes to deploy and configure DNSSEC | from that of a user who wishes to deploy and configure DNSSEC with | |||
| with only the safest algorithm. On the other hand, the comments and | only the safest algorithm. On the other hand, the comments and | |||
| recommendations in this document are also expected to be useful for | recommendations in this document are also expected to be useful for | |||
| such users. | such users. | |||
| 2. Conventions Used in This Document | 2. Conventions Used in This Document | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 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 cryptographics 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 that 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. | |||
| ECC-GOST (GOST R 34.10-2001) has been superseded by GOST R 34.10-2012 | ECC-GOST (GOST R 34.10-2001) has been superseded by GOST R 34.10-2012 | |||
| in [RFC7091]. The GOST R 34.10-2012 hasn't been standardized for use | in [RFC7091]. GOST R 34.10-2012 hasn't been standardized for use in | |||
| in DNSSEC. | DNSSEC. | |||
| ECDSAP256SHA256 provides more cryptographic strength with a shorter | ECDSAP256SHA256 provides more cryptographic strength with a shorter | |||
| signature length than either RSASHA256 or RSASHA512. ECDSAP256SHA256 | signature length than either RSASHA256 or RSASHA512. ECDSAP256SHA256 | |||
| has been widely deployed and therefore it is now at MUST level for | has been widely deployed and therefore it is now at MUST level for | |||
| both validation and signing. It is RECOMMENDED to use deterministic | both validation and signing. It is RECOMMENDED to use the | |||
| digital signature generation procedure of the ECDSA ([RFC6979]) when | deterministic digital signature generation procedure of the ECDSA | |||
| implementing ECDSAP256SHA256 (and ECDSAP384SHA384). | ([RFC6979]) when implementing ECDSAP256SHA256 (and ECDSAP384SHA384). | |||
| ECDSAP384SHA384 shares the same properties as ECDSAP256SHA256, but | ECDSAP384SHA384 shares the same properties as ECDSAP256SHA256, but | |||
| offers a modest security advantage over ECDSAP256SHA256 (192 bits of | offers a modest security advantage over ECDSAP256SHA256 (192 bits of | |||
| strength versus 128 bits). For most DNSSEC applications, | strength versus 128 bits). For most DNSSEC applications, | |||
| ECDSAP256SHA256 should be satisfactory and robust for the foreseeable | ECDSAP256SHA256 should be satisfactory and robust for the foreseeable | |||
| future, and is therefore recommended for signing. While it is | future, and is therefore recommended for signing. While it is | |||
| unlikely for a DNSSEC use case requiring 192-bit security strength to | unlikely for a DNSSEC use case requiring 192-bit security strength to | |||
| arise, ECDSA384SHA384 is provided for such applications and it MAY be | arise, ECDSA384SHA384 is provided for such applications and it MAY be | |||
| used for signing in these cases. | used for signing in these cases. | |||
| ED25519 and ED448 use Edwards-curve Digital Security Algorithm | ED25519 and ED448 use the Edwards-curve Digital Security Algorithm | |||
| (EdDSA). There are three main advantages of the EdDSA algorithm: It | (EdDSA). There are three main advantages of EdDSA: It does not | |||
| does not require the use of a unique random number for each | require the use of a unique random number for each signature, there | |||
| signature, there are no padding or truncation issues as with ECDSA, | are no padding or truncation issues as with ECDSA, and it is more | |||
| and it is more resilient to side-channel attacks. Furthermore, EdDSA | resilient to side-channel attacks. Furthermore, EdDSA cryptography | |||
| cryptography is less prone to implementation errors ([RFC8032], | is less prone to implementation errors ([RFC8032], [RFC8080]). It is | |||
| [RFC8080]). It is expected that ED25519 will become the future | expected that ED25519 will become the future RECOMMENDED default | |||
| RECOMMENDED default algorithm once there's enough support for this | algorithm once there's enough support for this algorithm in the | |||
| algorithm in the deployed DNSSEC validators. | deployed DNSSEC validators. | |||
| 3.2. DNSKEY Algorithm Recommendation | 3.2. DNSKEY Algorithm Recommendation | |||
| Operation recommendation for new and existing deployments. | Due to the industry-wide trend towards elliptic curve cryptography, | |||
| ECDSAP256SHA256 is the RECOMMENDED DNSKEY algorithm for use by new | ||||
| Due to industry-wide trend to move to elliptic curve cryptography, | DNSSEC deployments, and users of RSA-based algorithms SHOULD upgrade | |||
| the ECDSAP256SHA256 is RECOMMENDED DNSKEY algorithm for use by new | ||||
| 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 also apply to the CDS RRTYPE as specified in [RFC7344] | These recommendations 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 [*] | | |||
| | 1 | SHA-1 | MUST NOT | MUST | | | 1 | SHA-1 | MUST NOT | MUST | | |||
| | 2 | SHA-256 | MUST | MUST | | | 2 | SHA-256 | MUST | MUST | | |||
| | 3 | GOST R 34.11-94 | MUST NOT | MAY | | | 3 | GOST R 34.11-94 | MUST NOT | MAY | | |||
| | 4 | SHA-384 | MAY | RECOMMENDED | | | 4 | SHA-384 | MAY | RECOMMENDED | | |||
| +--------+-----------------+-------------------+-------------------+ | +--------+-----------------+-------------------+-------------------+ | |||
| [*] - This is a special type of CDS record signaling removal of DS at | [*] - This is a special type of CDS record signaling removal of DS at | |||
| the parent in [RFC8078] | the parent in [RFC8078]. | |||
| NULL is a special case, see [RFC8078] | NULL is a special case, see [RFC8078]. | |||
| 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 validation, but it MUST NOT be used to generate new DS and | implement validation, but it MUST NOT be used to generate new DS and | |||
| CDS records. (See Operational Considerations for caveats when | CDS records. (See Operational Considerations for caveats when | |||
| upgrading from SHA-1 to SHA-256 DS Algorithm.) | 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 superseded by GOST R 34.11-2012 in | GOST R 34.11-94 has been superseded by GOST R 34.11-2012 in | |||
| [RFC6986]. The GOST R 34.11-2012 hasn't been standardized for use in | [RFC6986]. GOST R 34.11-2012 has not been standardized for use in | |||
| DNSSEC. | DNSSEC. | |||
| 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-256 (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 | 3.4. DS and CDS Algorithm Recommendation | |||
| Operation recommendation for new and existing deployments. | Operation recommendation for new and existing deployments: SHA-256 is | |||
| the RECOMMENDED DS and CDS algorithm. | ||||
| 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 | ||||
| "mandatory-to-implement" algorithms. The algorithms identified in | ||||
| this document as MUST or RECOMMENDED to implement are not known to be | ||||
| broken at the current time, and cryptographic research so far leads | ||||
| 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 | 4. Implementation Status | |||
| DNSKEY algorithm rollover in a live zone is a complex process. See | [RFC Editor Note: Please remove this entire section plus all | |||
| [RFC6781] and [RFC7583] for guidelines on how to perform algorithm | references to [RFC7942] prior to publication as an RFC.] | |||
| rollovers. | ||||
| DS algorithm rollover in a live zone is also a complex process. | This section records the status of known implementations of the | |||
| Upgrading algorithm at the same time as rolling the new KSK key will | protocol defined by this specification at the time of posting of this | |||
| lead to DNSSEC validation failures, and users MUST upgrade the DS | Internet-Draft, and is based on a proposal described in [RFC7942]. | |||
| algorithm first before rolling the Key Signing Key. | 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. | ||||
| 6. Implementation Report | 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". | ||||
| 6.1. DNSKEY Algorithms | 4.1. DNSKEY Algorithms | |||
| The following table contains the status of support in the open-source | The following table contains the status of support in the open-source | |||
| DNS signers and validators in the current released versions as of the | DNS signers and validators in the current released versions as of the | |||
| time writing this document. Usually, the support for specific | time writing this document. Usually, the support for specific | |||
| algorithm has to be also included in the cryptographic libraries that | algorithm has to be also included in the cryptographic libraries that | |||
| the software use. | 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 | | |||
| | RSASHA256 | Y | Y | Y | Y | Y | | | RSASHA256 | Y | Y | Y | Y | Y | | |||
| | RSASHA512 | Y | Y | Y | Y | Y | | | RSASHA512 | Y | Y | Y | Y | Y | | |||
| | ECC-GOST | N | N | Y | Y | Y | | | ECC-GOST | N | N | Y | N | Y | | |||
| | ECDSAP256SHA256 | Y | Y | Y | Y | Y | | | ECDSAP256SHA256 | Y | Y | Y | Y | Y | | |||
| | ECDSAP384SHA384 | Y | Y | Y | Y | Y | | | ECDSAP384SHA384 | Y | Y | Y | Y | Y | | |||
| | ED25519 | Y | Y | N | Y | Y | | | ED25519 | Y | Y | N | Y | Y | | |||
| | ED448 | N | N | 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 use in DNSSEC, specifically with the selection of | ||||
| "mandatory-to-implement" algorithms. The algorithms identified in | ||||
| this document as MUST or RECOMMENDED to implement are not known to be | ||||
| broken (in the cryptographic sense) at the current time, and | ||||
| cryptographic research so far leads 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. | ||||
| 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. | ||||
| 7. IANA Considerations | 7. IANA Considerations | |||
| This document makes no requests of IANA. | This document makes no requests of IANA. | |||
| 8. Acknowledgements | 8. 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 Michael Sinatra, Roland van Rijswijk-Deij, Olafur | We wish to thank Michael Sinatra, Roland van Rijswijk-Deij, Olafur | |||
| Gudmundsson, Paul Hoffman and Evan Hunt for their imminent feedback. | Gudmundsson, Paul Hoffman, Evan Hunt, and Peter Yee for their | |||
| feedback. | ||||
| Kudos to Roy Arends for bringing the DS rollover issue to the | Kudos to Roy Arends for bringing the DS rollover issue to light. | |||
| daylight. | ||||
| 9. References | 9. References | |||
| 9.1. Normative References | 9.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, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
| 9.2. Informative References | ||||
| [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
| Rose, "Resource Records for the DNS Security Extensions", | Rose, "Resource Records for the DNS Security Extensions", | |||
| RFC 4034, DOI 10.17487/RFC4034, March 2005, | RFC 4034, DOI 10.17487/RFC4034, March 2005, | |||
| <https://www.rfc-editor.org/info/rfc4034>. | <https://www.rfc-editor.org/info/rfc4034>. | |||
| [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS | [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS | |||
| Security (DNSSEC) Hashed Authenticated Denial of | Security (DNSSEC) Hashed Authenticated Denial of | |||
| Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, | Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, | |||
| <https://www.rfc-editor.org/info/rfc5155>. | <https://www.rfc-editor.org/info/rfc5155>. | |||
| [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY | [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY | |||
| and RRSIG Resource Records for DNSSEC", RFC 5702, | and RRSIG Resource Records for DNSSEC", RFC 5702, | |||
| DOI 10.17487/RFC5702, October 2009, | DOI 10.17487/RFC5702, October 2009, | |||
| <https://www.rfc-editor.org/info/rfc5702>. | <https://www.rfc-editor.org/info/rfc5702>. | |||
| [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, <https://www.rfc-editor.org/info/rfc5933>. | ||||
| [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital | [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital | |||
| Signature Algorithm (DSA) for DNSSEC", RFC 6605, | Signature Algorithm (DSA) for DNSSEC", RFC 6605, | |||
| DOI 10.17487/RFC6605, April 2012, | DOI 10.17487/RFC6605, April 2012, | |||
| <https://www.rfc-editor.org/info/rfc6605>. | <https://www.rfc-editor.org/info/rfc6605>. | |||
| [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC | ||||
| Operational Practices, Version 2", RFC 6781, | ||||
| DOI 10.17487/RFC6781, December 2012, | ||||
| <https://www.rfc-editor.org/info/rfc6781>. | ||||
| [RFC6944] Rose, S., "Applicability Statement: DNS Security (DNSSEC) | ||||
| DNSKEY Algorithm Implementation Status", RFC 6944, | ||||
| DOI 10.17487/RFC6944, April 2013, | ||||
| <https://www.rfc-editor.org/info/rfc6944>. | ||||
| [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature | [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature | |||
| Algorithm (DSA) and Elliptic Curve Digital Signature | Algorithm (DSA) and Elliptic Curve Digital Signature | |||
| Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August | Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August | |||
| 2013, <https://www.rfc-editor.org/info/rfc6979>. | 2013, <https://www.rfc-editor.org/info/rfc6979>. | |||
| [RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: | [RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: | |||
| Hash Function", RFC 6986, DOI 10.17487/RFC6986, August | Hash Function", RFC 6986, DOI 10.17487/RFC6986, August | |||
| 2013, <https://www.rfc-editor.org/info/rfc6986>. | 2013, <https://www.rfc-editor.org/info/rfc6986>. | |||
| [RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012: | ||||
| Digital Signature Algorithm", RFC 7091, | ||||
| DOI 10.17487/RFC7091, December 2013, | ||||
| <https://www.rfc-editor.org/info/rfc7091>. | ||||
| [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, | ||||
| "DNSSEC Key Rollover Timing Considerations", RFC 7583, | ||||
| DOI 10.17487/RFC7583, October 2015, | ||||
| <https://www.rfc-editor.org/info/rfc7583>. | ||||
| [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital | [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital | |||
| Signature Algorithm (EdDSA)", RFC 8032, | Signature Algorithm (EdDSA)", RFC 8032, | |||
| DOI 10.17487/RFC8032, January 2017, | DOI 10.17487/RFC8032, January 2017, | |||
| <https://www.rfc-editor.org/info/rfc8032>. | <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>. | |||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
| 9.2. Informative References | ||||
| [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, <https://www.rfc-editor.org/info/rfc5933>. | ||||
| [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC | ||||
| Operational Practices, Version 2", RFC 6781, | ||||
| DOI 10.17487/RFC6781, December 2012, | ||||
| <https://www.rfc-editor.org/info/rfc6781>. | ||||
| [RFC6944] Rose, S., "Applicability Statement: DNS Security (DNSSEC) | ||||
| DNSKEY Algorithm Implementation Status", RFC 6944, | ||||
| DOI 10.17487/RFC6944, April 2013, | ||||
| <https://www.rfc-editor.org/info/rfc6944>. | ||||
| [RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012: | ||||
| Digital Signature Algorithm", RFC 7091, | ||||
| DOI 10.17487/RFC7091, December 2013, | ||||
| <https://www.rfc-editor.org/info/rfc7091>. | ||||
| [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, | ||||
| "DNSSEC Key Rollover Timing Considerations", RFC 7583, | ||||
| DOI 10.17487/RFC7583, October 2015, | ||||
| <https://www.rfc-editor.org/info/rfc7583>. | ||||
| [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, | ||||
| <https://www.rfc-editor.org/info/rfc7942>. | ||||
| [DNSKEY-IANA] | [DNSKEY-IANA] | |||
| "DNSKEY Algorithms", <http://www.iana.org/assignments/ | "DNSKEY Algorithms", <http://www.iana.org/assignments/ | |||
| dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml>. | dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml>. | |||
| [DS-IANA] "Delegation Signer Digest Algorithms", | [DS-IANA] "Delegation Signer Digest Algorithms", | |||
| <http://www.iana.org/assignments/ds-rr-types/ | <http://www.iana.org/assignments/ds-rr-types/ | |||
| ds-rr-types.xhtml>. | ds-rr-types.xhtml>. | |||
| Authors' Addresses | Authors' Addresses | |||
| End of changes. 42 change blocks. | ||||
| 132 lines changed or deleted | 165 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||