RFC 2539

RFC 2539 💖 Storage of Diffie-Hellman Keys in the Domain Name System (DNS)

Okay bestie, so this is RFC 2539 🎀 from March 1999. It was written by D. Eastlake, which is Donald E. Eastlake 3rd at IBM 🧚. It's a Standards Track doc, so it's a real protocol spec and not just vibes. It came out of the Network Working Group, and the title block doesn't list anything it obsoletes or updates, so it isn't replacing or patching anything else ✨.

Status of this Memo 📜

So this one says it's an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💅. For where the standardization state and status of this protocol actually sits, check the current "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.

Copyright Notice ⭐

Here's the legal bit, copied exactly 💅:

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

Abstract 🫶

Quick summary: this doc describes a standard way to store Diffie-Hellman keys in the Domain Name System, and it does that using DNS KEY resource records 🔑.

Acknowledgements 🙈

The format for Diffie-Hellman keys (and how it's described) was borrowed from a work in progress by these people 🌸:

   Ashar Aziz <ashar.aziz@eng.sun.com>
   Tom Markson <markson@incog.com>
   Hemma Prafullchandra <hemma@eng.sun.com>

These two folks also gave useful comments that got worked in 💜:

   Ran Atkinson <rja@inet.org>
   Thomas Narten <narten@raleigh.ibm.com>

Table of Contents 📚

Abstract...................................................1
Acknowledgements...........................................1
1. Introduction............................................2
1.1 About This Document....................................2
1.2 About Diffie-Hellman...................................2
2. Diffie-Hellman KEY Resource Records.....................3
3. Performance Considerations..............................4
4. IANA Considerations.....................................4
5. Security Considerations.................................4
References.................................................5
Author's Address...........................................5
Appendix A: Well known prime/generator pairs...............6
A.1. Well-Known Group 1:  A 768 bit prime..................6
A.2. Well-Known Group 2:  A 1024 bit prime.................6
Full Copyright Notice......................................7

1. Introduction ✨

The Domain Name System (DNS) is the current global hierarchical replicated distributed database system for Internet addressing, mail proxy, and similar information 🌍. The DNS has been extended to include digital signatures and cryptographic keys, as described in [RFC 2535]. So yes, the DNS can now be used for secure key distribution 🔐.

1.1 About This Document 📖

This doc explains how to store Diffie-Hellman keys in the DNS. It assumes you already know the Diffie-Hellman key exchange algorithm [Schneier], so no pressure, but go brush up if you need to 🙈.

1.2 About Diffie-Hellman 🦋

Diffie-Hellman needs two parties to interact so they can derive keying info, which they can then use for authentication. DNS SIG RRs are mainly used as stored authenticators of zone information for lots of different resolvers. Because of that, no Diffie-Hellman algorithm SIG RR is defined 💅.

Say two parties have local secrets "i" and "j". Each of them calculates X and Y like this:

                X = g**i ( mod p ) Y = g**j ( mod p )

They swap those values, and then each one calculates a Z like this:

                Zi = Y**i ( mod p ) Zj = X**j ( mod p )

The result is a shared secret between the two parties 🤝. An adversary who doesn't know i or j won't be able to learn it from the exchanged messages. The only way in is if they can derive i or j by doing a discrete logarithm mod p, which is hard for strong p and g 💀.

The private key for each party is their secret i (or j) 🗝️. The public key is the pair p and g, which must be the same for both parties, plus their individual X (or Y) 💜.

2. Diffie-Hellman KEY Resource Records 🔑

Diffie-Hellman keys get stored in the DNS as KEY RRs using algorithm number 2 ✨. The RDATA part of this RR is laid out like the diagram below. The first 4 octets (the flags, protocol, and algorithm fields) are shared by all KEY RRs, as described in [RFC 2535]. Everything from prime length through public value is the "public key" part of the KEY RR 🎀. The key's validity period isn't stored in the KEY RR at all. Instead, it's shown by the SIG RR(s) that sign and authenticate the KEY RR(s) at that domain name 🦋.

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           KEY flags           |    protocol   |  algorithm=2  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     prime length (or flag)    |  prime (p) (or special)       /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/  prime (p)  (variable length) |       generator length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| generator (g) (variable length)                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     public value length       | public value (variable length)/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/  public value (g^i mod p)    (variable length)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Prime length is the length of the Diffie-Hellman prime (p) in bytes, as long as it's 16 or greater 📏. Prime holds the binary representation of that Diffie-Hellman prime with the most significant byte first, which is network order 🌐.

Now here's the plot twist 🙀. If the "prime length" field is 1 or 2, then the "prime" field is actually an unsigned index into a table of 65,536 prime/generator pairs 📚. In that case the generator length SHOULD be zero. Check Appendix A for the defined table entries, and Section 4 for how to allocate extra table entries. The meaning of a zero or a 3 through 15 value for "prime length" is reserved 🚫.

Generator length is the length of the generator (g) in bytes. Generator is the binary representation of the generator, again with most significant byte first. PublicValueLen is the length of the Public Value (g**i (mod p)) in bytes. PublicValue is the binary representation of the DH public value, also with most significant byte first 💖.

The matching algorithm=2 SIG resource record isn't used, so no format for it is defined 💅.

3. Performance Considerations 🚀

Current DNS implementations are optimized for small transfers, usually less than 512 bytes including overhead 📦. Bigger transfers still work correctly, and work is underway to make them more efficient. Even so, it's still a good idea to make reasonable efforts to keep KEY RR sets stored in the DNS small, as long as the security stays adequate 🧘. Keep in mind that in a secure zone, an authenticating SIG RR will come back with them too 🔁.

---

Full Copyright Statement ✨

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

okay so the legal bit, bestie 💅 Anyone can copy and furnish this document and translations of it to others. You can also make derivative works that comment on or explain it, or help with implementing it, and prepare, copy, publish and distribute those in whole or in part with no restrictions of any kind 🫶. The only catch is that the copyright notice and this paragraph have to be included on all copies and derivative works.

BUT this 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. There are two exceptions: (1) developing Internet standards, where the copyright procedures in the Internet Standards process must be followed, and (2) translating it into languages other than English 🌸

The limited permissions above are perpetual, and the Internet Society or its successors or assigns will never revoke them. Forever and ever 💖

Now the disclaimer, which is all caps because it's serious 😭 This document and the information contained in it 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. Translation: they're not promising it's perfect, so read it with your own eyes 👑