idnits 2.17.1 draft-ietf-dnssec-dhk-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-dnssec-dhk-03.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-dhk-03.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-dhk-03.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-dnssec-dhk-03.txt,', but the file name used is 'draft-ietf-dnssec-dhk-03' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 158: '... generator length SHOULD be zero. See...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (May 1999) is 9111 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 1034' is defined on line 213, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 216, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' Summary: 11 errors (**), 1 flaw (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Diffie-Hellman Keys in the DNS 2 November 1998 3 Expires May 1999 5 Storage of Diffie-Hellman Keys in the Domain Name System (DNS) 6 ------- -- -------------- ---- -- --- ------ ---- ------ ----- 8 Donald E. Eastlake 3rd 10 Status of This Document 12 This draft, file name draft-ietf-dnssec-dhk-03.txt, is intended to be 13 become a Proposed Standard RFC. Distribution of this document is 14 unlimited. Comments should be sent to the DNS security mailing list 15 or to the author. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months. Internet-Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet- 25 Drafts as reference material or to cite them other than as a 26 ``working draft'' or ``work in progress.'' 28 To view the entire list of current Internet-Drafts, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 31 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 32 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 34 [Changes from previous draft: add IANA considerations section, update 35 author info, update file name and dates, add specific well known 36 groups] 38 Abstract 40 A standard method for storing Diffie-Hellman keys in the Domain Name 41 System is described which utilizes DNS KEY resource records. 43 Acknowledgements 45 Part of the format for Diffie-Hellman keys and the description 46 thereof was taken from an Internet draft by: 48 Ashar Aziz 49 Tom Markson 50 Hemma Prafullchandra 52 In addition, the following person provided useful comments that have 53 been incorporated: 55 Ran Atkinson 56 Thomas Narten 58 Table of Contents 60 Status of This Document....................................1 62 Abstract...................................................2 63 Acknowledgements...........................................2 65 Table of Contents..........................................3 67 1. Introduction............................................4 68 1.1 About This Document....................................4 69 1.2 About Diffie-Hellman...................................4 70 2. Diffie-Hellman KEY Resource Records.....................5 71 3. Performance Considerations..............................6 72 4. IANA Considerations.....................................6 73 5. Security Considerations.................................6 75 References.................................................7 76 Author's Address...........................................7 77 Expiration and File Name...................................7 79 Appendix A: Well known prime/generator pairs...............8 80 A.1. Well-Known Group 1: A 768 bit prime..................8 81 A.2. Well-Known Group 2: A 1024 bit prime.................8 83 1. Introduction 85 The Domain Name System (DNS) is the current global hierarchical 86 replicated distributed database system for Internet addressing, mail 87 proxy, and similar information. The DNS has been extended to include 88 digital signatures and cryptographic keys as described in [draft- 89 ietf-dnssec-secext2-*.txt]. Thus the DNS can now be used for secure 90 key distribution. 92 1.1 About This Document 94 This document describes how to store Diffie-Hellman keys in the DNS. 95 Familiarity with the Diffie-Hellman key exchange algorithm is assumed 96 [Schneier]. 98 1.2 About Diffie-Hellman 100 Diffie-Hellman requires two parties to interact to derive keying 101 information which can then be used for authentication. Since DNS SIG 102 RRs are primarily used as stored authenticators of zone information 103 for many different resolvers, no Diffie-Hellman algorithm SIG RR is 104 defined. For example, assume that two parties have local secrets "i" 105 and "j". Assume they each respectively calculate X and Y as follows: 107 X = g**i ( mod p ) 108 Y = g**j ( mod p ) 110 They exchange these quantities and then each calculates a Z as 111 follows: 113 Zi = Y**i ( mod p ) 114 Zj = X**j ( mod p ) 116 Zi and Zj will both be equal to g**(ij)(mod p) and will be a shared 117 secret between the two parties that an adversary who does not know i 118 or j will not be able to learn from the exchanged messages (unless 119 the adversary can derive i or j by performing a discrete logarithm 120 mod p which is hard for strong p and g). 122 The private key for each party is their secret i (or j). The public 123 key is the pair p and g, which must be the same for the parties, and 124 their individual X (or Y). 126 2. Diffie-Hellman KEY Resource Records 128 Diffie-Hellman keys are stored in the DNS as KEY RRs using algorithm 129 number 2. The structure of the RDATA portion of this RR is as shown 130 below. The first 4 octets, including the flags, protocol, and 131 algorithm fields are common to all KEY RRs as described in [draft- 132 ietf-dnssec-secext2-*.txt]. The remainder, from prime length through 133 public value is the "public key" part of the KEY RR. The period of 134 key validity is not in the KEY RR but is indicated by the SIG RR(s) 135 which signs and authenticates the KEY RR(s) at that domain name. 137 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | KEY flags | protocol | algorithm=2 | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | prime length (or flag) | prime (p) (or special) / 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 / prime (p) (variable length) | generator length | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | generator (g) (variable length) | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | public value length | public value (variable length)/ 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 / public value (g^i mod p) (variable length) | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 Prime length is length of the Diffie-Hellman prime (p) in bytes if it 154 is 16 or greater. Prime contains the binary representation of the 155 Diffie-Hellman prime with most significant byte first (i.e., in 156 network order). If "prime length" field is 1 or 2, then the "prime" 157 field is actually an unsigned index into a table of 65,536 158 prime/generator pairs and the generator length SHOULD be zero. See 159 Appedix A for defined table entries and Section 4 for information on 160 allocating additional table entries. The meaning of a zero or 3 161 through 15 value for "prime length" is reserved. 163 Generator length is the length of the generator (g) in bytes. 164 Generator is the binary representation of generator with most 165 significant byte first. PublicValueLen is the Length of the Public 166 Value (g**i (mod p)) in bytes. PublicValue is the binary 167 representation of the DH public value with most significant byte 168 first. 170 The corresponding algorithm=2 SIG resource record is not used so no 171 format for it is defined. 173 3. Performance Considerations 175 Current DNS implementations are optimized for small transfers, 176 typically less than 512 bytes including overhead. While larger 177 transfers will perform correctly and work is underway to make larger 178 transfers more efficient, it is still advisable to make reasonable 179 efforts to minimize the size of KEY RR sets stored within the DNS 180 consistent with adequate security. Keep in mind that in a secure 181 zone, an authenticating SIG RR will also be returned. 183 4. IANA Considerations 185 Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires 186 an IETF consensus. 188 Well known prime/generator pairs number 0x0000 through 0x07FF can 189 only be assigned by an IETF standards action and this Proposed 190 Standard assigns 0x0001 through 0x0002. Pairs number 0s0800 through 191 0xBFFF can be assigned based on RFC documentation. Pairs number 192 0xC000 through 0xFFFF are available for private use and are not 193 centrally coordinated. Use of such private pairs outside of a closed 194 environment may result in conflicts. 196 5. Security Considerations 198 Many of the general security consideration in [draft-ietf-dnssec- 199 secext2-*] apply. Keys retrieved from the DNS should not be trusted 200 unless (1) they have been securely obtained from a secure resolver or 201 independently verified by the user and (2) this secure resolver and 202 secure obtainment or independent verification conform to security 203 policies acceptable to the user. As with all cryptographic 204 algorithms, evaluating the necessary strength of the key is important 205 and dependent on local policy. 207 In addition, the usual Diffie-Hellman key strength considerations 208 apply. (p-1)/2 should also be prime, g should be primitive mod p, p 209 should be "large", etc. [Schneier] 211 References 213 [RFC 1034] - P. Mockapetris, "Domain names - concepts and 214 facilities", 11/01/1987. 216 [RFC 1035] - P. Mockapetris, "Domain names - implementation and 217 specification", 11/01/1987. 219 [draft-ietf-dnssec-secext2-*.txt] - Domain Name System Security 220 Extensions, D. Eastlake. 222 [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, 223 Algorithms, and Source Code in C", 1996, John Wiley and Sons 225 Author's Address 227 Donald E. Eastlake 3rd 228 IBM 229 318 Acton Street 230 Carlisle, MA 01741 USA 232 Telephone: +1-978-287-4877 233 +1-914-784-7913 234 FAX: +1-978-371-7148 235 EMail: dee3@us.ibm.com 237 Expiration and File Name 239 This draft expires in April 1999. 241 Its file name is draft-ietf-dnssec-dhk-03.txt. 243 Appendix A: Well known prime/generator pairs 245 These numbers are copied from the IPSEC effort where the derivation of 246 these values is more fully explained and additional information is available. 247 Richard Schroeppel performed all the mathematical and computational 248 work for this appendix. 250 A.1. Well-Known Group 1: A 768 bit prime 252 The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its 253 decimal value is 254 155251809230070893513091813125848175563133404943451431320235 255 119490296623994910210725866945387659164244291000768028886422 256 915080371891804634263272761303128298374438082089019628850917 257 0691316593175367469551763119843371637221007210577919 259 Prime modulus: Length (32 bit words): 24, Data (hex): 260 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 261 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 262 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 263 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF 265 Generator: Length (32 bit words): 1, Data (hex): 2 267 A.2. Well-Known Group 2: A 1024 bit prime 269 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 270 Its decimal value is 271 179769313486231590770839156793787453197860296048756011706444 272 423684197180216158519368947833795864925541502180565485980503 273 646440548199239100050792877003355816639229553136239076508735 274 759914822574862575007425302077447712589550957937778424442426 275 617334727629299387668709205606050270810842907692932019128194 276 467627007 278 Prime modulus: Length (32 bit words): 32, Data (hex): 279 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 280 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 281 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 282 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 283 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 284 FFFFFFFF FFFFFFFF 286 Generator: Length (32 bit words): 1, Data (hex): 2