RFC 6014

RFC 6014: Cryptographic Algorithm Identifier Allocation for DNSSEC 🎀

Okay bestie, here's the deets on RFC 6014 💖. It's a Standards Track doc from the IETF, written by Paul Hoffman of the VPN Consortium, dated November 2010 🗓️. It's an ISSN 2070-1721 thing, and it updates RFC 4033, RFC 4034, and RFC 4035 🔥. Nothing in this doc obsoletes anything.

Abstract

This doc is all about how DNSSEC cryptographic algorithm identifiers get allocated in the IANA registries 🧚. The big change: the requirement moves from "standard required" to "RFC Required" ✨. It does NOT change which algorithms are recommended or required for DNSSEC implementations, so the vibe on that stays the same 💅.

Status of This Memo

This is an Internet Standards Track document 🦋.

It's a product of the Internet Engineering Task Force (IETF) 🌸. It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 🫶. If you want more on Internet Standards, check Section 2 of RFC 5741 📚.

Info about the current status of this doc, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6014 🔗.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors 💜. All rights reserved.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date 📜. Please read these carefully, because they spell out your rights and restrictions for this doc 🙈. Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 💀.

This doc may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008 🍓. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😭. Unless you get an adequate license from them, this doc may NOT be modified outside the IETF Standards Process, and derivative works of it may NOT be created outside the IETF Standards Process 🚫. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈.

1. Introduction ✨

[RFC2535] says the IANA registry for DNS Security Algorithm Numbers gets updated by IETF Standards Action only 👑. The exceptions are two values, 253 and 254 🧚. Basically, for an algorithm to get its own spot in the registry, it has to be defined in a Standards Track RFC, as defined in [RFC2026] 💅. The same requirement shows up again in [RFC3755] and in the combo of [RFC4033], [RFC4034], and [RFC4035] 🔁.

RFC 2535 lets algorithms that aren't on the Standards Track use private values 253 and 254 in signatures 🎀. In each case, an unregistered private name must be included with each use of the algorithm so different algorithms that share a value can be told apart 🫶.

2. Requirements for Assignments in the DNS Security Algorithm Numbers Registry 🦋

This doc changes the registration rule from needing a Standards Track RFC to needing a published RFC of any type 🔥. There are two reasons for loosening it up:

• Some algorithms are genuinely useful but can't land in a Standards Track RFC 💖. For plenty of reasons, an algorithm might not have been evaluated thoroughly enough to be put on the Standards Track 🌸. Another example: the algorithm might have unclear intellectual property rights that keep it off the Standards Track 😭.
• The registry is restricted in size (about 250 entries), but new algorithms are proposed pretty rarely 🐢. It could easily be many decades before there's any reason to restrict the registry again 🕰️.

Some developers care about the standards level of the RFCs in the registry 🧐. The registry has been updated to show the current standards level of each listed algorithm ✨.

Now, about the registry eventually filling up 📦: the IETF should re-evaluate the requirements for entry into this registry when about 120 of the registry entries have been assigned 🚨. That evaluation might lead to tighter restrictions or a new way to extend the registry's size 🌈. To make that re-evaluation more likely to happen, IANA has marked about half of the currently available entries as "Reserved" so the timing is more obvious 👀.

The private-use values 253 and 254 are still super useful for developers who want to test algorithms in private when there's no RFC for them yet 🧪. This doc does NOT change what those two values mean 💅.

3. Expectations for Implementations 🧩

It's important to know that, according to RFC 4034, DNSSEC implementations are NOT expected to include every algorithm listed in the IANA registry 🙅‍♀️. In fact, RFC 4034 and the IANA registry list an algorithm that implementations should not include 😬. This doc doesn't change the expectation that some items in the IANA registry don't need to be (and in some cases shouldn't be) included in every implementation 💜.

There are lots of reasons a DNSSEC implementation might skip one or more of the listed algorithms, even ones on the Standards Track 🌸. To be compliant with RFC 4034, an implementation only needs to implement the algorithms listed as mandatory to implement in that standard, or in updates to that standard 📜. This doc doesn't change the mandatory-to-implement list in RFC 4034 🔒. It also doesn't change the requirements for when an algorithm becomes mandatory to implement 🙈. Those requirements should come in a separate, focused document 📝.

It should also be noted that the order of algorithms in the IANA registry does NOT signify or imply cryptographic strength or preference 🚫.

4. IANA Considerations 🧚

This doc updates the allocation requirements for unassigned values in the "Domain Name System Security (DNSSEC) Algorithm Numbers" registry at http://www.iana.org/assignments/dns-sec-alg-numbers, in the sub-registry titled "DNS Security Algorithm Numbers" 🗂️. The registration procedure for values assigned after this doc is published is "RFC Required" 🎀.

IANA has marked values 123 through 251 as "Reserved" 🔖. The registry notes that this reservation is made in RFC 6014 (this RFC), so when most of the unreserved values are taken, future users and IANA will have a pointer to where the reservation came from and what it's for 🕵️‍♀️.

IANA has also added a textual notation to the "References" column in the registry that gives the current standards status for each RFC listed there ✨.

5. Security Considerations 💀

An algorithm described in an RFC that is NOT on the Standards Track may have weaker security than one that is on the Standards Track 😱. In fact, that may be exactly why the algorithm wasn't allowed onto the Standards Track 🫣. BUT, not being on the Standards Track does NOT automatically mean an algorithm is weaker 🙅‍♀️. The reverse is also true: algorithms on the Standards Track should NOT necessarily be considered better than algorithms that aren't 🙃. There are other reasons, like intellectual property concerns, that can keep algorithms widely considered strong off the Standards Track ⚖️.

6. References 📚

6.1. Normative References

• [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. 🧚
• [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004. 🌸
• [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. 💜
• [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. 🎀
• [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. 🦋

6.2. Informative References

• [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 👑

Appendix A. Experimental and Documentation Values 🧪

During early discussion of this doc, someone proposed reserving a small number of values for "experimental" purposes 🔬. That proposal didn't make it into the doc because the IETF has a long history of experimental values becoming permanent 😭. Here's how it goes: a developer releases (maybe "experimentally") software with an experimental value tied to some extension, competitors code their systems to test interoperability, and then nobody wants to change their software's values to the "real" value that was assigned later 🙈.

There was also a proposal that IANA reserve two values for documentation only, kind of like how "example.com" is reserved as a domain name 📝. That didn't make it in either, because every value needs to be associated with some algorithm, and there's no problem with having examples that point to commonly deployed algorithms 🌈.

Author's Address 🫶

Paul Hoffman VPN Consortium

EMail: paul.hoffman@vpnc.org 💌