idnits 2.17.1 draft-ietf-dnssec-dss-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-dss-02.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-dss-02.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-dss-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-dss-02.txt,', but the file name used is 'draft-ietf-dnssec-dss-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 (July 1998) is 9417 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 196, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 199, 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: 11 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 January 1998 3 Expires July 1998 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-02.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 49 2. DSA KEY Resource Records................................4 51 3. DSA SIG Resource Records................................5 53 4. Performance Considerations..............................6 54 5. Security Considerations.................................6 56 References.................................................7 57 Author's Address...........................................7 58 Expiration and File Name...................................7 60 1. Introduction 62 The Domain Name System (DNS) is the global hierarchical replicated 63 distributed database system for Internet addressing, mail proxy, and 64 other information. The DNS has been extended to include digital 65 signatures and cryptographic keys as described in [draft-ietf- 66 dnssec-secext2-*]. Thus the DNS can now be secured and can be used 67 for secure key distribution. 69 This document describes how to store US Government Digital Signature 70 Algorithm (DSA) keys and signatures in the DNS. Familiarity with the 71 US Digital Signature Algorithm is assumed [Schneier]. Implementation 72 of DSA is mandatory for DNS security. 74 2. DSA KEY Resource Records 76 DSA public keys are stored in the DNS as KEY RRs using algorithm 77 number 3 [draft-ietf-dnssec-secext2-*]. The structure of the 78 algorithm specific portion of the RDATA part of this RR is as shown 79 below. These fields, from Q through Y are the "public key" part of 80 the DSA KEY RR. 82 The period of key validity is not in the KEY RR but is indicated by 83 the SIG RR(s) which signs and authenticates the KEY RR(s) at that 84 domain name. 86 Field Size 87 ----- ---- 88 T 1 octet 89 Q 20 octets 90 P 64 + T*8 octets 91 G 64 + T*8 octets 92 Y 64 + T*8 octets 94 As described in [FIPS 186] and [Schneier]: T is a key size parameter 95 chosen such that 0 <= T <= 8. (The meaning for algorithm 3 if the T 96 octet is greater than 8 is reserved and the remainder of the RDATA 97 portion may have a different format in that case.) Q is a prime 98 number selected at key generation time such that 2**159 < Q < 2**160 99 so Q is always 20 octets long and, as with all other fields, is 100 stored in "big-endian" network order. P, G, and Y are calculated as 101 directed by the FIPS 186 key generation algorithm [Schneier]. P is 102 in the range 2**(511+64T) < P < 2**(512+64T) and so is 64 + 8*T 103 octets long. G and Y are quantities modulus P and so can be up to 104 the same length as P and are allocated fixed size fields with the 105 same number of octets as P. 107 During the key generation process, a random number X must be 108 generated such that 1 <= X <= Q-1. X is the private key and is used 109 in the final step of public key generation where Y is computed as 111 Y = G**X mod P 113 3. DSA SIG Resource Records 115 The signature portion of the SIG RR RDATA area, when using the US 116 Digital Signature Algorithm, is shown below with fields in the order 117 they occur. See [draft-ietf-dnssec-secext2-*] for fields in the SIG 118 RR RDATA which precede the signature itself. 120 Field Size 121 ----- ---- 122 T 1 octet 123 R 20 octets 124 S 20 octets 126 The data signed is determined as specified in [draft-ietf-dnssec- 127 secext2-*]. Then the following steps are taken, as specified in 128 [FIPS 186], where Q, P, G, and Y are as specified in the public key 129 [Schneier]: 131 hash = SHA-1 ( data ) 133 Generate a random K such that 0 < K < Q. 135 R = ( G**K mod P ) mod Q 137 S = ( K**(-1) * (hash + X*R) ) mod Q 139 Since Q is 160 bits long, R and S can not be larger than 20 octets, 140 which is the space allocated. 142 T is copied from the public key. It is not logically necessary in 143 the SIG but is present so that values of T > 8 can more conveniently 144 be used as an escape for extended versions of DSA or other algorithms 145 as later specified. 147 4. Performance Considerations 149 General signature generation speeds are roughly the same for RSA [RFC 150 xRSA] and DSA. With sufficient pre-computation, signature generation 151 with DSA is faster than RSA. Key generation is also faster for DSA. 152 However, signature verification is an order of magnitude slower than 153 RSA when the RSA public exponent is chosen to be small as is 154 recommended for KEY RRs used in domain name system (DNS) data 155 authentication. 157 Current DNS implementations are optimized for small transfers, 158 typically less than 512 bytes including overhead. While larger 159 transfers will perform correctly and work is underway to make larger 160 transfers more efficient, it is still advisable at this time to make 161 reasonable efforts to minimize the size of KEY RR sets stored within 162 the DNS consistent with adequate security. Keep in mind that in a 163 secure zone, at least one authenticating SIG RR will also be 164 returned. 166 5. Security Considerations 168 Many of the general security consideration in [draft-ietf-dnssec- 169 secext2-*] apply. Keys retrieved from the DNS should not be trusted 170 unless (1) they have been securely obtained from a secure resolver or 171 independently verified by the user and (2) this secure resolver and 172 secure obtainment or independent verification conform to security 173 policies acceptable to the user. As with all cryptographic 174 algorithms, evaluating the necessary strength of the key is essential 175 and dependent on local policy. 177 The key size limitation of a maximum of 1024 bits ( T = 8 ) in the 178 current DSA standard may limit the security of DSA. For particularly 179 critical applications, implementors are encouraged to consider the 180 range of available algorithms and key sizes. 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. See [Schneier] and more recent 186 research. The leakage of an entire DSA private key in only two DSA 187 signatures has been demonstrated. DSA provides security only if 188 trusted implementations, including trusted random number generation, 189 are used. 191 References 193 [FIPS 186] - U.S. Federal Information Processing Standard: Digital 194 Signature Standard. 196 [RFC 1034] - P. Mockapetris, "Domain names - concepts and 197 facilities", 11/01/1987. 199 [RFC 1035] - P. Mockapetris, "Domain names - implementation and 200 specification", 11/01/1987. 202 [RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness 203 Recommendations for Security", 12/29/1994. 205 [draft-ietf-dnssec-secext2-*] - Domain Name System Security 206 Extensions, D. Eastlake, C. Kaufman, January 1997. 208 [RFC xRSA] - draft-ietf-dnssec-rsa-*.txt 210 [Schneier] - Bruce Schneier, "Applied Cryptography Second Edition: 211 protocols, algorithms, and source code in C", 1996, John Wiley and 212 Sons, ISBN 0-471-11709-9. 214 Author's Address 216 Donald E. Eastlake 3rd 217 CyberCash, Inc. 218 318 Acton Street 219 Carlisle, MA 01741 USA 221 Telephone: +1 978 287 4877 222 +1 703 620-4200 (main office, Reston, Virginia) 223 FAX: +1 978 371 7148 224 EMail: dee@cybercash.com 226 Expiration and File Name 228 This draft expires in July 1998. 230 Its file name is draft-ietf-dnssec-dss-02.txt.