idnits 2.17.1 draft-ietf-dnssec-dss-01.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-dss-01.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-dss-01.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-dss-01.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-dss-01.txt,', but the file name used is 'draft-ietf-dnssec-dss-01' == 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 (May 1998) is 9478 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 205, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 208, but no explicit reference was found in the text == Unused Reference: 'RFC 1750' is defined on line 211, but no explicit reference was found in the text == Unused Reference: 'RFC 2065' is defined on line 214, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 186' ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' Summary: 12 errors (**), 1 flaw (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT DSA KEYs and SIGs in the DNS 2 November 1997 3 Expires May 1998 5 DSA KEYs and SIGs in the Domain Name System 6 --- ---- --- ---- -- --- ------ ---- ------ 8 Donald E. Eastlake 3rd 10 Status of This Document 12 This draft, file name draft-ietf-dnssec-dss-01.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 learn the current status of any Internet-Draft, please check the 29 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 30 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 31 nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 32 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 34 Abstract 36 A standard method for storing US Government Digital Signature 37 Algorithm keys and signatures in the Domain Name System is described 38 which utilizes DNS KEY and SIG resource records. 40 Table of Contents 42 Status of This Document....................................1 43 Abstract...................................................1 45 Table of Contents..........................................2 47 1. Introduction............................................3 48 2. DSA KEY Resource Records................................3 50 3. DSA SIG Resource Records................................5 52 4. Performance Considerations..............................6 53 5. Security Considerations.................................6 55 References.................................................7 56 Author's Address...........................................7 57 Expiration and File Name...................................7 59 1. Introduction 61 The Domain Name System (DNS) is the global hierarchical replicated 62 distributed database system for Internet addressing, mail proxy, and 63 other information. The DNS has been extended to include digital 64 signatures and cryptographic keys as described in RFC 2065. Thus the 65 DNS can now be secured and used for secure key distribution. 67 This document describes how to store US Government Digital Signature 68 Algorithm (DSA) keys and signatures in the DNS. Familiarity with the 69 US Digital Signature Algorithm is assumed [Schneier]. 71 2. DSA KEY Resource Records 73 DSA public keys are stored in the DNS as KEY RRs using algorithm 74 number 3 (see RFC 2065). The structure of the RDATA portion of this 75 RR is as shown below. The first 4 octets, including the flags, 76 protocol, and algorithm fields are common to all KEY RRs. The 77 remainder, from Q through Y is the "public key" part of the KEY RR. 79 The period of key validity is not in the KEY RR but is indicated by 80 the SIG RR(s) which signs and authenticates the KEY RR(s) at that 81 domain name. 83 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 84 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 85 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 86 | flags | protocol | algorithm=3 | 87 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 88 | T | 89 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 90 | | 91 | Q (20 octets) | 92 | .../ 93 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | | 95 | P (64+T*8 octets) / 96 | .../ 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | | 99 | G (64+8*T octets) / 100 | .../ 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | | 103 | Y (64+8*T octets) / 104 | .../ 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 As described in [FIPS 186] and [Schneier]: T is a key size parameter 108 chosen such that 0 <= T <= 8. (The meaning for algorithm 3 if the T 109 octet is greater than 8 is reserved and the remainder of the RDATA 110 portion may have a different format in that case.) Q is a prime 111 number selected at key generation time such that 2**159 < Q < 2**160 112 so Q is always 20 octets long and, as with all other fields, is 113 stored in "big-endian" network order. P, G, and Y are calculated as 114 directed by the FIPS 186 key generation algorithm [Schneier]. P is 115 in the range 2**(511+64T) < P < 2**(512+64T) and so is 64 + 8*T 116 octets long. G and Y are quantities modulus P and so can be up to 117 the same length as P and are allocated fixed size fields with the 118 same number of octets as P. 120 During the key generation process, a random number X must be 121 generated such that 1 <= X <= Q-1. X is the private key and is used 122 in the final step of public key generation where Y is computed as 124 Y = G**X mod P 126 3. DSA SIG Resource Records 128 The signature portion of the SIG RR RDATA area, when using the US 129 Digital Signature Algorithm, is shown below. See RFC 2065 for fields 130 in the SIG RR RDATA which precede the signature itself. 132 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 133 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 134 +-+-+-+-+-+-+-+-+ 135 | T | 136 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | | 138 | R, 20 octets | 139 | .../ 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | | 142 | S, 20 octets | 143 | .../ 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 The data signed is determined as specified in RFC 2065. Then the 147 following steps are taken, as specified in [FIPS 186], where Q, P, G, 148 and Y are as specified in the public key [Schneier]: 150 hash = SHA-1 ( data ) 152 Generate random K such that 0 < K < Q. 154 R = ( G**K mod P ) mod Q 156 S = ( K**(-1) * (hash + X*R) ) mod Q 158 Since Q is 160 bits long, R and S can not be larger than 20 octets, 159 which is the space allocated. 161 T is copied from the public key. It is not logically necessary in 162 the SIG but is present so that values of T > 8 can more conveniently 163 be used as an escape for extended versions of DSA or other algorithms 164 as later specified. 166 4. Performance Considerations 168 Signature generation speeds are roughly the same for RSA and DSA. 169 Key generation is faster for DSA. Signature verification is an order 170 of magnitude slower than RSA. 172 Current DNS implementations are optimized for small transfers, 173 typically less than 512 bytes including overhead. While larger 174 transfers will perform correctly and work is underway to make larger 175 transfers more efficient, it is still advisable at this time to make 176 reasonable efforts to minimize the size of KEY RR sets stored within 177 the DNS consistent with adequate security. Keep in mind that in a 178 secure zone, an authenticating SIG RR will also be returned. 180 5. Security Considerations 182 DSA assumes the ability to frequently generate high quality random 183 numbers. See RFC 1750 for guidance. DSA is designed so that if 184 manipulated rather than random numbers are used, very high bandwidth 185 covert channels are possible [Schneier]. The leakage of an entire 186 DSA private key in only two DSA signatures has been demonstrated. 187 Thus DSA provides security only if trusted implementations, including 188 trusted random number generation, are used. 190 The key size limitation of a maximum of 1024 bits ( T = 8 ) limits 191 the security of DSA. For particularly critical high level keys, 192 sizes of 2048 and larger are now used in RSA. 194 Many of the general security consideration in RFC 2065 apply. Of 195 course, the DSA key stored in the DNS for an entity should not be 196 trusted unless it has been obtain via a trusted DNS resolver that 197 vouches for its security or unless the application using the key has 198 done a similar authentication. 200 References 202 [FIPS 186] - U.S. Federal Information Processing Standard: Digital 203 Signature Standard. 205 [RFC 1034] - P. Mockapetris, "Domain names - concepts and 206 facilities", 11/01/1987. 208 [RFC 1035] - P. Mockapetris, "Domain names - implementation and 209 specification", 11/01/1987. 211 [RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness 212 Recommendations for Security", 12/29/1994. 214 [RFC 2065] - Domain Name System Security Extensions, D. Eastlake, C. 215 Kaufman, January 1997. 217 [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, 218 Algorithms, and Source Code in C", 1996, John Wiley and Sons 220 Author's Address 222 Donald E. Eastlake 3rd 223 CyberCash, Inc. 224 318 Acton Street 225 Carlisle, MA 01741 USA 227 Telephone: +1 978 287 4877 228 +1 703 620-4200 (main office, Reston, VA) 229 FAX: +1 978 371 7148 230 EMail: dee@cybercash.com 232 Expiration and File Name 234 This draft expires in May 1998. 236 Its file name is draft-ietf-dnssec-dss-01.txt.