idnits 2.17.1 draft-ietf-dnssec-dhk-02.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-26) 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-02.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-dhk-02.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-dhk-02.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-02.txt,', but the file name used is 'draft-ietf-dnssec-dhk-02' == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (September 1998) is 9355 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 184, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 187, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' Summary: 10 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 Expires September 1998 4 Storage of Diffie-Hellman Keys in the Domain Name System (DNS) 5 ------- -- -------------- ---- -- --- ------ ---- ------ ----- 7 Donald E. Eastlake 3rd 9 Status of This Document 11 This draft, file name draft-ietf-dnssec-dhk-02.txt, is intended to be 12 become a Proposed Standard RFC. Distribution of this document is 13 unlimited. Comments should be sent to the DNS security mailing list 14 or to the author. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months. Internet-Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet- 24 Drafts as reference material or to cite them other than as a 25 ``working draft'' or ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 29 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 30 ftp.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 31 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 33 Abstract 35 A standard method for storing Diffie-Hellman keys in the Domain Name 36 System is described which utilizes DNS KEY resource records. 38 Acknowledgements 40 Part of the format for Diffie-Hellman keys and the description 41 thereof was taken from an Internet draft by: 43 Ashar Aziz 44 Tom Markson 45 Hemma Prafullchandra 47 In addition, the following person provided useful comments that have 48 been incorporated: 50 Ran Atkinson 52 Table of Contents 54 Status of This Document....................................1 56 Abstract...................................................2 57 Acknowledgements...........................................2 59 Table of Contents..........................................3 61 1. Introduction............................................4 63 2. Diffie-Hellman KEY Resource Records.....................5 65 3. Performance Considerations..............................6 66 4. Security Considerations.................................6 68 References.................................................7 69 Author's Address...........................................7 70 Expiration and File Name...................................7 72 1. Introduction 74 The Domain Name System (DNS) is the current global hierarchical 75 replicated distributed database system for Internet addressing, mail 76 proxy, and similar information. The DNS has been extended to include 77 digital signatures and cryptographic keys as described in [draft- 78 ietf-dnssec-secext2-*.txt]. Thus the DNS can now be used for secure 79 key distribution. 81 This document describes how to store Diffie-Hellman keys in the DNS. 82 Familiarity with the Diffie-Hellman key exchange algorithm is assumed 83 [Schneier]. 85 Diffie-Hellman requires two parties to interact to derive keying 86 information which can then be used for authentication. Since DNS SIG 87 RRs are primarily used as stored authenticators of zone information 88 for many different resolvers, no Diffie-Hellman algorithm SIG RR is 89 defined. For example, assume that two parties have local secrets "i" 90 and "j". Assume they each respectively calculate X and Y as follows: 92 X = g**i ( mod p ) 93 Y = g**j ( mod p ) 95 They exchange these quantities and then each calculates a Z as 96 follows: 98 Zi = Y**i ( mod p ) 99 Zj = X**j ( mod p ) 101 Zi and Zj will both be equal to g**(ij)(mod p) and will be a shared 102 secret between the two parties that an adversary who does not know i 103 or j will not be able to learn from the exchanged messages (unless 104 the adversary can derive i or j by performing a discrete logarithm 105 mod p which is hard for strong p and g). 107 The private key for each party is their secret i (or j). The public 108 key is the pair p and g which must be the same for the parties and 109 their individual X (or Y). 111 2. Diffie-Hellman KEY Resource Records 113 Diffie-Hellman keys are stored in the DNS as KEY RRs using algorithm 114 number 2. The structure of the RDATA portion of this RR is as shown 115 below. The first 4 octets, including the flags, protocol, and 116 algorithm fields are common to all KEY RRs as described in [draft- 117 ietf-dnssec-secext2-*.txt]. The remainder, from prime length through 118 public value is the "public key" part of the KEY RR. The period of 119 key validity is not in the KEY RR but is indicated by the SIG RR(s) 120 which signs and authenticates the KEY RR(s) at that domain name. 122 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 123 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 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | KEY flags | protocol | algorithm=2 | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | prime length (or flag) | prime (p) (or special) / 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 / prime (p) (variable length) | generator length | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | generator (g) (variable length) | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | public value length | public value (variable length)/ 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 / public value (g^i mod p) (variable length) | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 Prime length is length of the Diffie-Hellman prime (p) in bytes if it 139 is 16 or greater. Prime contains the binary representation of the 140 Diffie-Hellman prime with most significant byte first (i.e., in 141 network order). If "prime length" field is 1 or 2, then the "prime" 142 field is actually an unsigned index into a table of up to 65,536 143 predefined prime/generator pairs to be defined in which case the 144 generator length should be zero. The meaning of a zero or 3 through 145 15 value for "prime length" is reserved. 147 Generator length is the length of the generator (g) in bytes. 148 Generator is the binary representation of generator with most 149 significant byte first. PublicValueLen is the Length of the Public 150 Value (g**i (mod p)) in bytes. PublicValue is the binary 151 representation of the DH public value with most significant byte 152 first. 154 The corresponding algorithm=2 SIG resource record is not used so no 155 format for it is defined. 157 3. Performance Considerations 159 Current DNS implementations are optimized for small transfers, 160 typically less than 512 bytes including overhead. While larger 161 transfers will perform correctly and work is underway to make larger 162 transfers more efficient, it is still advisable at this time to make 163 reasonable efforts to minimize the size of KEY RR sets stored within 164 the DNS consistent with adequate security. Keep in mind that in a 165 secure zone, an authenticating SIG RR will also be returned. 167 4. Security Considerations 169 Many of the general security consideration in [draft-ietf-dnssec- 170 secext2-*] apply. Keys retrieved from the DNS should not be trusted 171 unless (1) they have been securely obtained from a secure resolver or 172 independently verified by the user and (2) this secure resolver and 173 secure obtainment or independent verification conform to security 174 policies acceptable to the user. As with all cryptographic 175 algorithms, evaluating the necessary strength of the key is essential 176 and dependent on local policy. 178 In addition, the usual Diffie-Hellman key strength considerations 179 apply. (p-1)/2 should also be prime, g should be primitive mod p, p 180 should be "large", etc. [Schneier] 182 References 184 [RFC 1034] - P. Mockapetris, "Domain names - concepts and 185 facilities", 11/01/1987. 187 [RFC 1035] - P. Mockapetris, "Domain names - implementation and 188 specification", 11/01/1987. 190 [draft-ietf-dnssec-secext2-*.txt] - Domain Name System Security 191 Extensions, D. Eastlake. 193 [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, 194 Algorithms, and Source Code in C", 1996, John Wiley and Sons 196 Author's Address 198 Donald E. Eastlake 3rd 199 CyberCash, Inc. 200 318 Acton Street 201 Carlisle, MA 01741 USA 203 Telephone: +1 978 287 4877 204 +1 703 620-4200 (main office, Reston, VA) 205 FAX: +1 978 371 7148 206 EMail: dee@cybercash.com 208 Expiration and File Name 210 This draft expires in September 1998. 212 Its file name is draft-ietf-dnssec-dhk-02.txt.