RFC 8624

Algorithm Implementation Requirements and Usage Guidance for DNSSEC

📅 published June 2019, from ietf

RFC 8624: Algorithm Implementation Requirements and Usage Guidance for DNSSEC 🎀

Internet Engineering Task Force (IETF) 🌸 Request for Comments: 8624 Obsoletes: RFC 6944 Category: Standards Track 💅 ISSN: 2070-1721 Date: June 2019

Okay bestie, this one is by P. Wouters (Red Hat) and O. Sury (Internet Systems Consortium) 👑. It's on the Standards Track, it came out in June 2019, and it obsoletes RFC 6944 🦋. Let's get into it ✨

Abstract 🦋

So DNSSEC uses a bunch of cryptographic algorithms to prove that DNS data is legit and to prove that a name doesn't exist 🔐. For resolvers and authoritative servers to actually work together, there has to be a set of algorithm requirements and usage guidelines, so that there's at least one algorithm every implementation supports 🫶. This document is where the current algorithm requirements and usage guidance for DNSSEC live. It obsoletes RFC 6944 💖.

Status of This Memo 🌸

This is an Internet Standards Track document 💅.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841 📚.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8624 🔗.

Copyright (c) 2019 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License 📜.

Table of Contents 📖

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Updating Algorithm Implementation Requirements and Usage
        Guidance  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.2.  Updating Algorithm Requirement Levels . . . . . . . . . .   3
  1.3.  Document Audience . . . . . . . . . . . . . . . . . . . .   4
2.  Conventions Used in This Document . . . . . . . . . . . . . .   4
3.  Algorithm Selection . . . . . . . . . . . . . . . . . . . . .   5
  3.1.  DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . .   5
  3.2.  DNSKEY Algorithm Recommendation . . . . . . . . . . . . .   6
  3.3.  DS and CDS Algorithms . . . . . . . . . . . . . . . . . .   7
  3.4.  DS and CDS Algorithm Recommendation . . . . . . . . . . .   7
4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
5.  Operational Considerations  . . . . . . . . . . . . . . . . .   8
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
  7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1. Introduction ✨

The DNSSEC signing algorithms are defined across a bunch of RFCs, including [RFC4034], [RFC5155], [RFC5702], [RFC5933], [RFC6605], and [RFC8080] 📚. DNSSEC is how we authenticate data 🔐. To keep everything interoperable, there's a set of "mandatory-to-implement" DNSKEY algorithms 🫶. This document obsoletes [RFC6944] 🦋.

1.1. Updating Algorithm Implementation Requirements and Usage Guidance

Cryptography is always changing, no cap 🌈. New, stronger algorithms show up, and algorithms we already trust turn out to be less secure than everyone thought 😭. Attacks that used to be computationally infeasible get more accessible as computing power goes up 💻. So the algorithm requirements and usage guidance need updating every so often to match the new reality ✨. The algorithm choices must be conservative to minimize the risk of algorithm compromise 🛡️.

1.2. Updating Algorithm Requirement Levels

The mandatory-to-implement algorithm of tomorrow should already be in most DNSSEC implementations by the time it becomes mandatory 🔮. This document tries to find those algorithms and introduce them for future mandatory-to-implement status 💅. There's no guarantee that today's algorithms become mandatory later, lowkey 🙈. Published algorithms keep getting hit with cryptographic attacks, and they may become too weak or even completely broken before this document gets updated 💀.

This document only gives recommendations about mandatory-to-implement algorithms, or about algorithms so weak that they can't be recommended 🚫. Any algorithm listed in the [DNSKEY-IANA] and [DS-IANA] registries that this document doesn't mention MAY be implemented 🌸. For clarity and consistency, an algorithm only gets specified as MAY in this document when it has been downgraded from a MUST or a RECOMMENDED to a MAY 📉.

Even though the main goal here is to update algorithm recommendations so DNSSEC authentication stays secure over time, the document also aims to keep DNSSEC implementations interoperable 🫶. DNSSEC interoperability is handled by introducing or deprecating algorithms gradually 🦋.

[RFC2119] considers the term SHOULD equivalent to RECOMMENDED, and SHOULD NOT equivalent to NOT RECOMMENDED. The authors chose to use the terms RECOMMENDED and NOT RECOMMENDED, since that more clearly shows the intent to implementers 💡.

Deprecating an algorithm is expected to happen gradually, over a series of updates to this document ⏳. That gives various implementations time to update their algorithms while staying interoperable 🧚. Unless there are strong security reasons, an algorithm is expected to be downgraded from MUST to NOT RECOMMENDED or MAY, instead of straight to MUST NOT 🫧. In the same way, an algorithm that was never listed as mandatory-to-implement is expected to be introduced with a RECOMMENDED instead of a MUST 🌱.

Using an unknown DNSKEY algorithm makes the zone get treated as insecure, so it is recommended that algorithms downgraded to NOT RECOMMENDED or lower not be used by authoritative nameservers and DNSSEC signers to create new DNSKEYs 🙅‍♀️. This lets deprecated algorithms become less and less common over time 📉. Once an algorithm reaches a low enough level of deployment, it can be marked as MUST NOT, so recursive resolvers can drop support for validating it 🧹.

Recursive nameservers are encouraged to keep supporting every algorithm that isn't marked as MUST NOT 🫶.

1.3. Document Audience

The recommendations here mostly target DNSSEC implementers 🧑‍💻, because implementations need to hit both high security expectations and high interoperability between vendors and different versions 💪. Interoperability needs a smooth move to more secure algorithms 🌈. This view might be different from a user who just wants to deploy and configure DNSSEC with only the safest algorithm 🔒. But the comments and recommendations in this document are also meant to be useful for those users 💖.

2. Conventions Used in This Document 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀. Lowercase versions are just regular words, periodt 💅.

3. Algorithm Selection 🧚

Part 2 picks up right here with the rest of Section 3 🦋👀

3.1. DNSKEY Algorithms 🔐

okay bestie, let's talk DNSKEY algorithms 💅 here's the implementation recommendations table from [DNSKEY-IANA], the one that tells you what to sign with and what to validate:

+--------+--------------------+-----------------+-------------------+
| Number | Mnemonics          | DNSSEC Signing  | DNSSEC Validation |
+--------+--------------------+-----------------+-------------------+
| 1      | RSAMD5             | MUST NOT        | MUST NOT          |
| 3      | DSA                | MUST NOT        | MUST NOT          |
| 5      | RSASHA1            | NOT RECOMMENDED | MUST              |
| 6      | DSA-NSEC3-SHA1     | MUST NOT        | MUST NOT          |
| 7      | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | MUST              |
| 8      | RSASHA256          | MUST            | MUST              |
| 10     | RSASHA512          | NOT RECOMMENDED | MUST              |
| 12     | ECC-GOST           | MUST NOT        | MAY               |
| 13     | ECDSAP256SHA256    | MUST            | MUST              |
| 14     | ECDSAP384SHA384    | MAY             | RECOMMENDED       |
| 15     | ED25519            | RECOMMENDED     | RECOMMENDED       |
| 16     | ED448              | MAY             | RECOMMENDED       |
+--------+--------------------+-----------------+-------------------+

RSAMD5 is not widely deployed 🙈 and the industry is trying to move away from MD5 usage, so it's giving retired vibes.

RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed 🫶 but zones using them are recommended to switch to ECDSAP256SHA256, because everyone is moving toward elliptic curve cryptography. RSASHA1 does not support NSEC3. RSASHA1-NSEC3-SHA1 can be used with or without NSEC3.

DSA and DSA-NSEC3-SHA1 are not widely deployed 😬 and they are vulnerable to private key compromise when signatures are generated with a weak or compromised random number generator. Yikes.

RSASHA256 is widely used and considered strong 💪 It has been the default algorithm for years, and it's now slowly being replaced by ECDSAP256SHA256 because its keys and signatures are shorter, which means smaller DNS packets ✨

RSASHA512 is NOT RECOMMENDED for DNSSEC signing 🙅 because it hasn't seen wide deployment. There are some deployments out there though, so DNSSEC validation MUST implement RSASHA512 to make sure everything interoperates. There's no significant difference in cryptographic strength between RSASHA512 and RSASHA256, so using RSASHA512 is discouraged. It would only make deprecating the older algorithms harder. If you want a cryptographically stronger algorithm, switch to elliptic curve cryptography algorithms 💜

ECC-GOST (GOST R 34.10-2001) has been superseded by GOST R 34.10-2012 in [RFC7091] 🌸 GOST R 34.10-2012 hasn't been standardized for use in DNSSEC, so no.

ECDSAP256SHA256 gives you more cryptographic strength with a shorter signature than either RSASHA256 or RSASHA512 👑 It's been widely deployed, so it is now at MUST level for both validation and signing. It is RECOMMENDED to use the deterministic digital signature generation procedure of the Elliptic Curve Digital Signature Algorithm (ECDSA), specified in [RFC6979], when implementing ECDSAP256SHA256 (and ECDSAP384SHA384).

ECDSAP384SHA384 has the same properties as ECDSAP256SHA256 but offers a modest security advantage, 192 bits of strength versus 128 bits 🦋 For most DNSSEC applications, ECDSAP256SHA256 should be satisfactory and robust for the foreseeable future, so it is therefore recommended for signing. It's unlikely a DNSSEC use case will need 192-bit security strength, but ECDSA384SHA384 is provided for those applications, and it MAY be used for signing in these cases.

ED25519 and ED448 use the Edwards-curve Digital Security Algorithm (EdDSA) 🧚 There are three main advantages of EdDSA. It does not require a unique random number for each signature, it has no padding or truncation issues like ECDSA does, and it is more resilient to side-channel attacks. EdDSA cryptography is also less prone to implementation errors ([RFC8032], [RFC8080]) 🙌 It is expected that ED25519 will become the future RECOMMENDED default algorithm once enough deployed DNSSEC validators support it.

3.2. DNSKEY Algorithm Recommendation 🎀

Because of the industry-wide move toward elliptic curve cryptography, ECDSAP256SHA256 is the RECOMMENDED DNSKEY algorithm for new DNSSEC deployments 🌈 and users of RSA-based algorithms SHOULD upgrade to ECDSAP256SHA256.

3.3. DS and CDS Algorithms 🍓

The following table lists the recommendations for Delegation Signer Digest Algorithms [DS-IANA] 📋 These recommendations also apply to the Child Delegation Signer (CDS) RRTYPE, as specified in [RFC7344].

+--------+-----------------+-------------------+-------------------+
| Number | Mnemonics       | DNSSEC Delegation | DNSSEC Validation |
+--------+-----------------+-------------------+-------------------+
| 0      | NULL (CDS only) | MUST NOT [*]      | MUST NOT [*]      |
| 1      | SHA-1           | MUST NOT          | MUST              |
| 2      | SHA-256         | MUST              | MUST              |
| 3      | GOST R 34.11-94 | MUST NOT          | MAY               |
| 4      | SHA-384         | MAY               | RECOMMENDED       |
+--------+-----------------+-------------------+-------------------+
[*] - This is a special type of CDS record signaling removal of DS at
                      the parent in [RFC8078].

NULL is a special case, so check out [RFC8078] for the details 🙃

SHA-1 is still widely used for Delegation Signer (DS) records 🕰️ so validators MUST implement validation, but it MUST NOT be used to generate new DS and CDS records. (See "Operational Considerations" for caveats when upgrading from the SHA-1 to SHA-256 DS algorithm.)

SHA-256 is widely used and considered strong 💅

GOST R 34.11-94 has been superseded by GOST R 34.11-2012 in [RFC6986] 🫠 GOST R 34.11-2012 has not been standardized for use in DNSSEC.

SHA-384 has the same properties as SHA-256 but offers a modest security advantage, 384 bits of strength versus 256 bits ✨ For most applications of DNSSEC, SHA-256 should be satisfactory and robust for the foreseeable future, so it is therefore recommended for DS and CDS records. It's unlikely a DNSSEC use case will need 384-bit security strength, but SHA-384 is provided for those applications, and it MAY be used for generating DS and CDS records in these cases.

3.4. DS and CDS Algorithm Recommendation 🏆

An operational recommendation for new and existing deployments: SHA-256 is the RECOMMENDED DS and CDS algorithm. Main character energy 👑

4. Security Considerations 🔒

The security of cryptographic systems depends on both the strength of the algorithms you pick and the strength of the keys you use with them 🔑 It also depends on the engineering of the protocol, which has to make sure there are no non-cryptographic ways to get around the security of the whole system. Don't skip this part, bestie 😭

This document is about picking cryptographic algorithms for DNSSEC, specifically the "mandatory-to-implement" ones. The algorithms marked here as MUST or RECOMMENDED to implement are not known to be broken (in the cryptographic sense) right now, and cryptographic research so far suggests they're likely to stay secure for the foreseeable future. But that isn't forever 🥺 so new revisions of this document will be issued from time to time to reflect current best practices.

Retiring an algorithm too soon would downgrade a zone signed with that retired algorithm to the equivalent of an unsigned zone 💀 So algorithm deprecation must be done very slowly, and only after careful consideration and measurement of its use. Slow and steady 🐢

5. Operational Considerations 🛠️

DNSKEY algorithm rollover in a live zone is a complex process 😵‍💫 See [RFC6781] and [RFC7583] for guidelines on how to do algorithm rollovers.

DS algorithm rollover in a live zone is also complex 🥴 Upgrading an algorithm at the same time as rolling a new Key Signing Key (KSK) will cause DNSSEC validation failures. Administrators MUST complete the DS algorithm upgrade before starting a rollover process for a new KSK. Do not combine these, besties ⚠️

Upgrading the DS algorithm and rolling a new KSK in the same window is a recipe for validation failures. Finish the DS upgrade first, then roll the KSK 🫶

6. IANA Considerations 📭

This document has no IANA actions ✨

7. References 📚

7.1. Normative References 💖

7.2. Informative References

Okay, bestie, now we're in the "further reading" zone 📚✨ These are the references the spec points to for background, not the stuff you must follow.

Acknowledgements ✨🫶

Okay, the credit list is giving "we stand on the shoulders of giants" 🙌 This document borrows text from RFC 4307 by Jeffrey I. Schiller of the Massachusetts Institute of Technology (MIT) and from RFC 8247 by Yoav Nir, Tero Kivinen, Paul Wouters, and Daniel Migault. Honestly, a lot of the original text was copied verbatim, and that's totally fine because it's already perfect 💅

We also want to thank Michael Sinatra, Roland van Rijswijk-Deij, Olafur Gudmundsson, Paul Hoffman, Evan Hunt, and Peter Yee for their feedback. You all are iconic 💖

And a huge kudos to Roy Arends for bringing the DS rollover issue to light. Main character energy 👑🔥

Authors' Addresses 🦋

Paul Wouters Red Hat Canada

Email: pwouters@redhat.com

Ondrej Sury Internet Systems Consortium Czech Republic

Email: ondrej@isc.org

📦 where this page comes from