RFC 2541

RFC 2541: DNS Security Operational Considerations ✨

Okay bestie, let's get the basics out of the way 🎀. This one is from D. Eastlake of IBM (Donald E. Eastlake 3rd, whose full address is at the end). It came out in the Network Working Group in March 1999 and is classed as Informational 📚. The header doesn't list it as obsoleting or updating any other RFC, so it just stands on its own 💅.

Status of this Memo 🌸

This memo is here to give information to the Internet community. It is not a standard of any kind 🙅‍♀️. Distribution of this memo is unlimited 🦋.

Copyright Notice 💜

Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract 💖

Okay so secure DNS runs on cryptography, and the strength of that crypto depends a LOT on how you handle your keys and signatures operationally. That means careful attention to how they're generated, how long they live, how big they are, and where they're stored 🔐. Special care is also needed for the high level zones, especially the root zone 👑. This doc walks through all of that for the keys and signatures used with the KEY and SIG DNS resource records ✨.

Acknowledgments 🫶

Huge thanks to these folks (listed alphabetically) for their contributions and suggestions 💅:

• John Gilmore
• Olafur Gudmundsson
• Charlie Kaufman

Table of Contents 🧚

Abstract...................................................1
Acknowledgments............................................1
1. Introduction............................................2
2. Public/Private Key Generation...........................2
3. Public/Private Key Lifetimes............................2
4. Public/Private Key Size Considerations..................3
4.1 RSA Key Sizes..........................................3
4.2 DSS Key Sizes..........................................4
5. Private Key Storage.....................................4
6. High Level Zones, The Root Zone, and The Meta-Root Key..5
7. Security Considerations.................................5
References.................................................6
Author's Address...........................................6
Full Copyright Statement...................................7

1. Introduction 🦋

So this doc is all about the operational side of DNS cryptographic keys and signatures: how they get generated, how long they last, how big they are, and how they're stored 🔑. It's for use with the KEY and SIG resource records [RFC 2535]. The high level zones and the root zone get extra special attention 👑.

2. Public/Private Key Generation 🎀

Generating keys carefully is lowkey the most overlooked step, but it's absolutely essential 😭. Even the strongest algorithms with the longest keys are useless if an adversary can guess enough to shrink the likely key space so it can be searched exhaustively 💀. You'll find technical suggestions for generating random keys in [RFC 1750] 📖.

Long term keys are especially sensitive, because they're a more valuable target and stay exposed to attack for longer than short period keys 🎯. It is strongly recommended that long term key generation happen off-line, isolated from the network by an air gap or, at a minimum, high level secure hardware 🔒.

3. Public/Private Key Lifetimes ⏳

No key should be used forever 🙅‍♀️. The longer a key is in use, the greater the chance it gets compromised through carelessness, accident, espionage, or cryptanalysis 😬. Also, if key rollover is a rare event, there's a risk that when the time finally comes, nobody on site remembers how to do it, or the rollover procedures have developed operational problems 🙈.

Public key lifetime is a matter of local policy, but these considerations imply that, unless there are extraordinary circumstances, no long term key should have a lifetime significantly over four years 📅. Honestly, a reasonable guideline for long term keys that are kept off-line and carefully guarded is a 13 month lifetime, with the intent that they be replaced every year 🍓. A reasonable maximum lifetime for keys used for transaction security or the like that are kept on line is 36 days, with the intent that they be replaced monthly or even more often 🔄. In many cases, a key lifetime of somewhat over a day may be reasonable ✨.

Keys that are too short-lived are a trap too 🪤. Public keys with too short a lifetime can cause excessive resource consumption from re-signing data and retrieving fresh information, because cached information goes stale. In the Internet environment, almost all public keys should have lifetimes no shorter than three minutes 🕒, which is a reasonable estimate of maximum packet delay even in unusual circumstances.

4. Public/Private Key Size Considerations 📏

There are a bunch of factors that affect public key size choice for the DNS security extension, and they usually don't all point the same way 🙃. Choosing a zone key size should generally be done by the zone administrator, based on their local conditions 🧑‍💻.

For most schemes, larger keys are more secure but slower 🐢. Larger keys also make the KEY and SIG RRs bigger 📦. That raises the chance of DNS UDP packet overflow, and the possible need for higher overhead TCP in responses 😵.

4.1 RSA Key Sizes 💅

Given a small public exponent, verification (the most common operation) for the MD5/RSA algorithm varies roughly with the square of the modulus length 📐. Signing varies with the cube of the modulus length, and key generation (the least common operation) varies with the fourth power of the modulus length 🧮. The current best algorithms for factoring a modulus and breaking RSA security vary roughly with the 1.6 power of the modulus itself 🧠. So going from a 640 bit modulus to a 1280 bit modulus only increases verification time by a factor of 4, but it may increase the work factor of breaking the key by over 2^900 🤯.

The recommended minimum RSA algorithm modulus size is 704 bits, which the author believes is secure at this time ✅. But high level zones in the DNS tree may want to set a higher minimum, perhaps 1000 bits, for security reasons 👑. (The United States National Security Agency generally permits export of encryption systems using an RSA modulus of up to 512 bits, so use of a modulus that small, i.e. n, must be considered weak 🚨.)

For an RSA key used only to secure data and not to secure other keys, 704 bits should be adequate at this time 🌈.

4.2 DSS Key Sizes 🎶

DSS keys are probably roughly as strong as an RSA key of the same length, but DSS signatures are significantly smaller 🥰.

Full Copyright Statement 💅

Copyright (C) The Internet Society (1999). All Rights Reserved. 🎀

okay so this is the legal bit, but it's still lowkey important, bestie 🫶 Anyone can copy this document and hand it to others. You can also make derivative works that comment on or explain it, or that help people implement it. Those can be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, as long as the above copyright notice and this paragraph are included on every copy and derivative work. ✨

The document itself can't be modified in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions: when it's needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or when it's translated into languages other than English. 🌸

The limited permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns. Forever, literally 🦋

Last part, and it's the disclaimer. It's in all caps because it's serious 💀

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.