RFC 2536

DSA KEYs and SIGs in the Domain Name System (DNS)

📅 published March 1999, from ietf

RFC 2536: DSA KEYs and SIGs in the Domain Name System (DNS) 💖

Okay bestie, the header info first 🧚

  • Network Working Group 🌸
  • Author: D. EastLake, Donald E. Eastlake 3rd, IBM 💅
  • Category: Standards Track ✨
  • Date: March 1999 📅
  • Obsoletes / Updates: none listed in the header 🫶

Status of This Memo 🎀

Okay so this is an Internet standards track protocol for the Internet community, and it's open for discussion and suggestions for improvements. For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) document. Distribution of this memo is unlimited 🦋

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

Abstract 🔥

This describes a standard way to store US Government Digital Signature Algorithm keys and signatures in the Domain Name System, using DNS KEY and SIG resource records. It's giving clean and organized 💅

Table of Contents 📚

Abstract...................................................1
1. Introduction............................................1
2. DSA KEY Resource Records................................2
3. DSA SIG Resource Records................................3
4. Performance Considerations..............................3
5. Security Considerations.................................4
6. IANA Considerations.....................................4
References.................................................5
Author's Address...........................................5
Full Copyright Statement...................................6

1. Introduction ✨

Okay so the Domain Name System (DNS) is the global, hierarchical, replicated, distributed database system for Internet addressing, mail proxy, and other info. Then DNS got extended with digital signatures and cryptographic keys, as described in [RFC 2535]. That means DNS can now be secured and used for secure key distribution. It's a whole glow-up 🦋

This document explains how to store US Government Digital Signature Algorithm (DSA) keys and signatures in DNS. Familiarity with the US Digital Signature Algorithm is assumed [Schneier]. And implementing DSA is mandatory for DNS security. Non-negotiable, bestie 🫶

2. DSA KEY Resource Records 🔑

DSA public keys get stored in DNS as KEY RRs using algorithm number 3 [RFC 2535]. The algorithm-specific part of the RDATA for this RR looks like the table below. The fields from Q through Y are the "public key" part of the DSA KEY RR 💖

The period of key validity is not stored in the KEY RR. Instead it's indicated by the SIG RR(s) that sign and authenticate the KEY RR(s) at that domain name. Main character energy 👑

        Field     Size
        -----     ----
         T         1  octet
         Q        20  octets
         P        64 + T*8  octets
         G        64 + T*8  octets
         Y        64 + T*8  octets

As described in [FIPS 186] and [Schneier]: T is a key size parameter chosen such that 0 <= T <= 8. (If the T octet is greater than 8, the meaning for algorithm 3 is reserved, and the rest of the RDATA may have a different format in that case 🙈) Q is a prime number picked at key generation time so that 2159 < Q < 2160. That means Q is always 20 octets long, and like all the other fields, it's stored in "big-endian" network order 🌸

P, G, and Y get calculated as the FIPS 186 key generation algorithm directs [Schneier]. P is in the range 2(511+64T) < P < 2(512+64T), so it's 64 + 8*T octets long. G and Y are quantities modulo P, so they can be up to the same length as P. They get fixed size fields with the same number of octets as P. Iconic 😭

During key generation, a random number X must be generated such that 1 <= X <= Q-1. X is the private key. It's used in the final step of public key generation, where Y is computed as:

          Y = G**X mod P

3. DSA SIG Resource Records ✍️

When you use the US Digital Signature Algorithm, the signature part of the SIG RR RDATA looks like the table below, with fields listed in the order they occur. For the fields in SIG RR RDATA that come before the signature itself, see [RFC 2535] 🎀

        Field     Size
        -----     ----
         T         1 octet
         R        20 octets
         S        20 octets

The data that gets signed is determined as [RFC 2535] specifies. Then these steps happen, as [FIPS 186] specifies, where Q, P, G, and Y are as given in the public key [Schneier]:

        hash = SHA-1 ( data )

        Generate a random K such that 0 < K < Q.

        R = ( G**K mod P ) mod Q

        S = ( K**(-1) * (hash + X*R) ) mod Q

Since Q is 160 bits long, R and S can't be larger than 20 octets, which is the space allocated. Tiny but mighty 🦋

T is copied from the public key. It isn't logically necessary in the SIG, but it's there so that values of T > 8 can conveniently act as an escape for extended versions of DSA or other algorithms specified later 🧚

4. Performance Considerations 🚀

Signature generation speeds are roughly the same for RSA [RFC 2537] and DSA. With enough pre-computation, DSA signature generation is faster than RSA. Key generation is also faster for DSA. Plot twist though: signature verification is an order of magnitude slower than RSA when the RSA public exponent is small, which is what's recommended for KEY RRs used in DNS data authentication 😬

Current DNS implementations are optimized for small transfers, typically less than 512 bytes including overhead. Larger transfers will work correctly, and work is underway to make them more efficient. Still, it's advisable right now to make reasonable efforts to keep the size of KEY RR sets stored in DNS small, while still staying secure enough. Also keep in mind that in a secure zone, at least one authenticating SIG RR will also get returned 💅

5. Security Considerations 💀

Lots of the general security considerations in [RFC 2535] apply here. Keys pulled from DNS should not be trusted unless (1) they were securely obtained from a secure resolver or independently verified by the user, and (2) that secure resolver and secure obtainment or independent verification follow security policies the user finds acceptable. As with all cryptographic algorithms, evaluating how strong the key needs to be is essential, and it depends on local policy 🔐

The key size limit of a maximum of 1024 bits ( T = 8 ) in the current DSA standard may limit the security of DSA. For especially critical applications, implementors are encouraged to consider the range of available algorithms and key sizes. 😭

DSA assumes you can frequently generate high quality random numbers. See [RFC 1750] for guidance. DSA is designed so that if manipulated rather than random numbers are used, very high bandwidth covert channels are possible. See [Schneier] and more recent research. Also, the leakage of an entire DSA private key from only two DSA signatures has been demonstrated. DSA only provides security when trusted implementations are used, including trusted random number generation 🙈🔥

6. IANA Considerations 📋

Giving meaning to values of the T parameter that aren't defined here requires an IETF standards action. The values left unallocated here are intended to cover future extensions of the DSS standard 🌈

References 📖

[FIPS 186]   U.S. Federal Information Processing Standard: Digital
             Signature Standard.

[RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
             Facilities", STD 13, RFC 1034, November 1987.

[RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
             Specification", STD 13, RFC 1035, November 1987.

[RFC 1750]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
             Recommendations for Security", RFC 1750, December 1994.

[RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
             RFC 2535, March 1999.

[RFC 2537]   Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
             System (DNS)", RFC 2537, March 1999.

[Schneier]   Schneier, B., "Applied Cryptography Second Edition:
             protocols, algorithms, and source code in C", 1996.

Author's Address 📮

Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road, RR #1
Carmel, NY 10512

Phone:   +1-914-276-2668(h)
         +1-914-784-7913(w)
Fax:     +1-914-784-3833(w)
EMail:   dee3@us.ibm.com

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

This document and translations of it can be copied and handed out to others. Derivative works that comment on or explain it, or help with implementing it, can be written, copied, published, and distributed, in whole or in part, with no restrictions at all, as long as the copyright notice and this paragraph are included on all copies and derivative works. However, this document itself may not be changed in any way, like by removing the copyright notice or references to the Internet Society or other Internet organizations. The exceptions are when it's needed to develop Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or when it's translated into a language other than English 🌸

The permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns ✨

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, 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. 🫶

📦 where this page comes from