RFC 3110

RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)

📅 published May 2001, from ietf

RFC 3110: RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) 🎀

Okay bestie, this one is from the Network Working Group and was written by Donald E. Eastlake 3rd of Motorola in May 2001 🦋. It's a Standards Track doc, and it obsoletes RFC 2537 💅. So if you've been using RFC 2537 for RSA stuff, this is the glow-up that replaces it ✨.

Status of this Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 💬. For the current standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.

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

Abstract 🧁

So this doc explains how to make RSA/SHA1 SIG resource records (RRs) in Section 3 💖, and, to completely replace RFC 2537, how to make RSA KEY RRs in Section 2 🫶.

Ever since a Proposed Standard for RSA signatures in the DNS (Domain Name Space) got adopted, hashing has had a major level-up ⬆️. A new DNS signature algorithm is defined so those advances show up in SIG RRs ✨. The older, weaker mechanism is deprecated 🙅‍♀️. The algorithm number of the RSA KEY RR is changed to match this new SIG algorithm 🔢. No other changes are made to DNS security, so nothing else is getting shaken up 🎀.

Acknowledgements 🫶

Material and comments from the following have been incorporated, and they are gratefully acknowledged 💜:

  • Olafur Gudmundsson
  • The IESG
  • Charlie Kaufman
  • Steve Wang

Table of Contents 🗺️

   1. Introduction................................................... 2
   2. RSA Public KEY Resource Records................................ 3
   3. RSA/SHA1 SIG Resource Records.................................. 3
   4. Performance Considerations..................................... 4
   5. IANA Considerations............................................ 5
   6. Security Considerations........................................ 5
   References........................................................ 5
   Author's Address.................................................. 6
   Full Copyright Statement.......................................... 7

1. Introduction 🌸

okay so the Domain Name System (DNS) is the global hierarchical, replicated, distributed database system for Internet addressing, mail proxy, and other information [RFC1034, 1035, etc.] 🌐. The DNS has been extended to include digital signatures and cryptographic keys, as described in [RFC2535] 🔐. So the DNS can now be secured and used for secure key distribution, which is lowkey iconic 👑.

Familiarity with the RSA and SHA-1 algorithms is assumed in this document [Schneier, FIP180] 🧠.

RFC 2537 described how to store RSA keys and RSA/MD5 based signatures in the DNS 📦. But since RFC 2537 came out, continued cryptographic research has revealed hints of weakness in the MD5 [RFC1321] algorithm that RFC 2537 used 😬. The SHA1 Secure Hash Algorithm [FIP180] was developed, and it produces a larger hash 📈. By now there's enough experience with SHA1 that it's generally acknowledged to be stronger than MD5 💪. Yes, this stronger hash is probably not needed today in most secure DNS zones 🤷‍♀️. But critical zones, such as the root, most top level domains, and some second and third level domains, are sufficiently valuable targets that it would be negligent not to provide what are generally agreed to be stronger mechanisms 🚨. Future advances in cryptanalysis and/or computer speeds may also require a stronger hash everywhere 🔮. And the extra computation SHA1 needs over MD5 is insignificant compared with the computational effort required by RSA modular exponentiation 🧮. It's giving "small cost, big payoff" 💅.

This document describes how to produce RSA/SHA1 SIG RRs in Section 3 🎀, and, so as to completely replace RFC 2537, describes how to produce RSA KEY RRs in Section 2 ✨.

Implementation of the RSA algorithm in DNS with SHA1 is MANDATORY for DNSSEC 🏆. The generation of RSA/MD5 SIG RRs as described in RFC 2537 is NOT RECOMMENDED 🙅‍♀️. Not me saying "don't use the old stuff" 💀, but yes, that's exactly the vibe 🫠.

The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", "NOT RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 📚. These are the official requirement-level words, so read them carefully 🔍.

2. RSA Public KEY Resource Records 🔑

RSA public keys are stored in the DNS as KEY RRs using algorithm number 5 [RFC2535] 🔢. The structure of the algorithm-specific portion of the RDATA part of these RRs is shown below 🗂️.

      Field             Size
      -----             ----
      exponent length   1 or 3 octets (see text)
      exponent          as specified by length field
      modulus           remaining space

For interoperability, the exponent and modulus are each limited to 4096 bits in length 📏. The public key exponent is a variable length unsigned integer 🔢. Its length in octets is represented as one octet if it is in the range of 1 to 255 🌸. It's represented by a zero octet followed by a two octet unsigned length if it is longer than 255 bytes 🧩. The public key modulus field is a multiprecision unsigned integer 💎. The length of the modulus can be figured out from the RDLENGTH and the preceding RDATA fields, including the exponent 🧠. Leading zero octets are prohibited in the exponent and modulus 🚫.

Note: KEY RRs for use with RSA/SHA1 DNS signatures MUST use this algorithm number, rather than the algorithm number specified in the obsoleted RFC 2537 ⭐.

Note: This changes the algorithm number for RSA KEY RRs to be the same as the new algorithm number for RSA/SHA1 SIGs 🎀. Matching numbers, no cap, very clean ✨.

3. RSA/SHA1 SIG Resource Records 🧾

RSA/SHA1 signatures are stored in the DNS using SIG resource records (RRs) with algorithm number 5 🖊️.

When using the RSA/SHA1 algorithm, the signature portion of the SIG RR RDATA area is calculated as shown below 🧮. The data signed is determined as specified in RFC 2535, and you can see RFC 2535 for the fields in the SIG RR RDATA that come before the signature itself 📖.

      hash = SHA1 ( data )

      signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n)

Where SHA1 is the message digest algorithm documented in [FIP180] 🌀. "|" is concatenation 🔗. "e" is the private key exponent of the signer 🗝️, and "n" is the modulus of the signer's public key 🔐. The values 01, FF, and 00 are fixed octets of the corresponding hexadecimal value 🎯. "prefix" is the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1 [RFC2437], which is:

hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14

This prefix is included to make it easier to use standard cryptographic libraries 🧰. The FF octet MUST be repeated the maximum number of times such that the value of the quantity being exponentiated is one octet shorter than the value of n 🔁. That's a very precise slay 💅.

(The above specifications are identical to the corresponding parts of Public Key Cryptographic Standard #1 [RFC2437] 📘.)

The size of "n", including most and least significant bits (which will be 1), MUST be not less than 512 bits and not more than 4096 bits 📏. "n" and "e" SHOULD be chosen such that the public exponent is small 🪶. These are protocol limits 🚧. For a discussion of key size, see RFC 2541 🔎.

Leading zero bytes are permitted in the RSA/SHA1 algorithm signature 🌊.

That's the end of part 1 🌈💖

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

Okay, so you can totally copy this document and share it with people, and you can make derivative works that comment on it, explain it, or help people implement it. You can publish and distribute those too, in whole or in part, with no restriction of any kind 🦋. The one condition is that the above copyright notice and this paragraph have to be included on every copy and derivative work 🫶.

BUT (and this is a big but 😭) the document itself may not be modified in any way. That means no removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are 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 a language other than English 🌍.

The permissions above are perpetual, so the Internet Society and its successors or assigns won't revoke them 💜. Literally forever ✨.

This document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED. That includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and any implied warranties of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE 🙈.

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society 🧚✨

📦 where this page comes from