idnits 2.17.1 draft-ietf-dnssec-dss-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-03-28) 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-03.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-dss-03.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-dss-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-dss-03.txt,', but the file name used is 'draft-ietf-dnssec-dss-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. 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 (April 1999) is 9114 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 204, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 207, 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' Summary: 10 errors (**), 1 flaw (~~), 5 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 October 1998 3 Expires April 1999 5 DSA KEYs and SIGs 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-dss-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: change dates, update author info, add 35 IANA Considerations] 37 Abstract 39 A standard method for storing US Government Digital Signature 40 Algorithm keys and signatures in the Domain Name System is described 41 which utilizes DNS KEY and SIG resource records. 43 Table of Contents 45 Status of This Document....................................1 46 Abstract...................................................1 48 Table of Contents..........................................2 50 1. Introduction............................................3 51 2. DSA KEY Resource Records................................3 52 3. DSA SIG Resource Records................................4 53 4. Performance Considerations..............................4 54 5. Security Considerations.................................5 55 6. IANA Considerations.....................................5 57 References.................................................6 58 Author's Address...........................................6 59 Expiration and File Name...................................6 61 1. Introduction 63 The Domain Name System (DNS) is the global hierarchical replicated 64 distributed database system for Internet addressing, mail proxy, and 65 other information. The DNS has been extended to include digital 66 signatures and cryptographic keys as described in [draft-ietf- 67 dnssec-secext2-*]. Thus the DNS can now be secured and can be used 68 for secure key distribution. 70 This document describes how to store US Government Digital Signature 71 Algorithm (DSA) keys and signatures in the DNS. Familiarity with the 72 US Digital Signature Algorithm is assumed [Schneier]. Implementation 73 of DSA is mandatory for DNS security. 75 2. DSA KEY Resource Records 77 DSA public keys are stored in the DNS as KEY RRs using algorithm 78 number 3 [draft-ietf-dnssec-secext2-*]. The structure of the 79 algorithm specific portion of the RDATA part of this RR is as shown 80 below. These fields, from Q through Y are the "public key" part of 81 the DSA KEY RR. 83 The period of key validity is not in the KEY RR but is indicated by 84 the SIG RR(s) which signs and authenticates the KEY RR(s) at that 85 domain name. 87 Field Size 88 ----- ---- 89 T 1 octet 90 Q 20 octets 91 P 64 + T*8 octets 92 G 64 + T*8 octets 93 Y 64 + T*8 octets 95 As described in [FIPS 186] and [Schneier]: T is a key size parameter 96 chosen such that 0 <= T <= 8. (The meaning for algorithm 3 if the T 97 octet is greater than 8 is reserved and the remainder of the RDATA 98 portion may have a different format in that case.) Q is a prime 99 number selected at key generation time such that 2**159 < Q < 2**160 100 so Q is always 20 octets long and, as with all other fields, is 101 stored in "big-endian" network order. P, G, and Y are calculated as 102 directed by the FIPS 186 key generation algorithm [Schneier]. P is 103 in the range 2**(511+64T) < P < 2**(512+64T) and so is 64 + 8*T 104 octets long. G and Y are quantities modulus P and so can be up to 105 the same length as P and are allocated fixed size fields with the 106 same number of octets as P. 108 During the key generation process, a random number X must be 109 generated such that 1 <= X <= Q-1. X is the private key and is used 110 in the final step of public key generation where Y is computed as 112 Y = G**X mod P 114 3. DSA SIG Resource Records 116 The signature portion of the SIG RR RDATA area, when using the US 117 Digital Signature Algorithm, is shown below with fields in the order 118 they occur. See [draft-ietf-dnssec-secext2-*] for fields in the SIG 119 RR RDATA which precede the signature itself. 121 Field Size 122 ----- ---- 123 T 1 octet 124 R 20 octets 125 S 20 octets 127 The data signed is determined as specified in [draft-ietf-dnssec- 128 secext2-*]. Then the following steps are taken, as specified in 129 [FIPS 186], where Q, P, G, and Y are as specified in the public key 130 [Schneier]: 132 hash = SHA-1 ( data ) 134 Generate a random K such that 0 < K < Q. 136 R = ( G**K mod P ) mod Q 138 S = ( K**(-1) * (hash + X*R) ) mod Q 140 Since Q is 160 bits long, R and S can not be larger than 20 octets, 141 which is the space allocated. 143 T is copied from the public key. It is not logically necessary in 144 the SIG but is present so that values of T > 8 can more conveniently 145 be used as an escape for extended versions of DSA or other algorithms 146 as later specified. 148 4. Performance Considerations 150 General signature generation speeds are roughly the same for RSA [RFC 151 xRSA] and DSA. With sufficient pre-computation, signature generation 152 with DSA is faster than RSA. Key generation is also faster for DSA. 153 However, signature verification is an order of magnitude slower than 154 RSA when the RSA public exponent is chosen to be small as is 155 recommended for KEY RRs used in domain name system (DNS) data 156 authentication. 158 Current DNS implementations are optimized for small transfers, 159 typically less than 512 bytes including overhead. While larger 160 transfers will perform correctly and work is underway to make larger 161 transfers more efficient, it is still advisable at this time to make 162 reasonable efforts to minimize the size of KEY RR sets stored within 163 the DNS consistent with adequate security. Keep in mind that in a 164 secure zone, at least one authenticating SIG RR will also be 165 returned. 167 5. 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 The key size limitation of a maximum of 1024 bits ( T = 8 ) in the 179 current DSA standard may limit the security of DSA. For particularly 180 critical applications, implementors are encouraged to consider the 181 range of available algorithms and key sizes. 183 DSA assumes the ability to frequently generate high quality random 184 numbers. See [RFC 1750] for guidance. DSA is designed so that if 185 manipulated rather than random numbers are used, very high bandwidth 186 covert channels are possible. See [Schneier] and more recent 187 research. The leakage of an entire DSA private key in only two DSA 188 signatures has been demonstrated. DSA provides security only if 189 trusted implementations, including trusted random number generation, 190 are used. 192 6. IANA Considerations 194 Allocation of meaning to values of the T parameter that are not 195 defined herein requires an IETF standards actions. It is intended 196 that values unallocated herein be used to cover future extensions of 197 the DSS standard. 199 References 201 [FIPS 186] - U.S. Federal Information Processing Standard: Digital 202 Signature Standard. 204 [RFC 1034] - P. Mockapetris, "Domain names - concepts and 205 facilities", 11/01/1987. 207 [RFC 1035] - P. Mockapetris, "Domain names - implementation and 208 specification", 11/01/1987. 210 [RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness 211 Recommendations for Security", 12/29/1994. 213 [draft-ietf-dnssec-secext2-*] - Domain Name System Security 214 Extensions, D. Eastlake, C. Kaufman, January 1997. 216 [RFC xRSA] - draft-ietf-dnssec-rsa-*.txt - RSA/MD5 KEYs and SIGs in 217 the Domain Name System (DNS), D. Eastlake. 219 [Schneier] - Bruce Schneier, "Applied Cryptography Second Edition: 220 protocols, algorithms, and source code in C", 1996, John Wiley and 221 Sons, ISBN 0-471-11709-9. 223 Author's Address 225 Donald E. Eastlake 3rd 226 IBM 227 318 Acton Street 228 Carlisle, MA 01741 USA 230 Telephone: +1-978-287-4877 231 +1-914-784-7913 232 FAX: +1-978-371-7148 233 EMail: dee3@us.ibm.com 235 Expiration and File Name 237 This draft expires in April 1999. 239 Its file name is draft-ietf-dnssec-dss-03.txt.