idnits 2.17.1 draft-ietf-dnssec-rsa-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-25) 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-rsa-01.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-rsa-01.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-rsa-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-rsa-01.txt,', but the file name used is 'draft-ietf-dnssec-rsa-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. ** 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 124: '...). The FF octet MUST be repeated the ...' RFC 2119 keyword, line 132: '... be 1) MUST be not less than 512 bit...' RFC 2119 keyword, line 133: '... and e SHOULD be chosen such that th...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 95 has weird spacing: '...nted as one o...' == 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 9142 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 189, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 192, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'NETSEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS1' ** Downref: Normative reference to an Informational RFC: RFC 1321 -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' Summary: 12 errors (**), 1 flaw (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT RSA/MD5 KEYs and SIGs in the DNS 2 October 1998 3 Expires April 1999 5 RSA/MD5 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-rsa-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 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 the previous draft: change date, update author info, 35 add RFC 2119 reference] 37 Abstract 39 A standard method for storing RSA keys and and RSA/MD5 based 40 signatures in the Domain Name System is described which utilizes DNS 41 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. RSA Public KEY Resource Records.........................3 53 3. RSA/MD5 SIG Resource Records............................4 55 4. Performance Considerations..............................5 56 5. Security Considerations.................................5 58 References.................................................6 59 Author's Address...........................................6 60 Expiration and File Name...................................6 62 1. Introduction 64 The Domain Name System (DNS) is the global hierarchical replicated 65 distributed database system for Internet addressing, mail proxy, and 66 other information. The DNS has been extended to include digital 67 signatures and cryptographic keys as described in [draft-ietf- 68 dnssec-secext2-*]. Thus the DNS can now be secured and used for 69 secure key distribution. 71 This document describes how to store RSA keys and and RSA/MD5 based 72 signatures in the DNS. Familiarity with the RSA algorithm is assumed 73 [Schneier]. Implementation of the RSA algorithm in DNS is 74 recommended. 76 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" 77 in this document are to be interpreted as described in RFC 2119. 79 2. RSA Public KEY Resource Records 81 RSA public keys are stored in the DNS as KEY RRs using algorithm 82 number 1 [draft-ietf-dnssec-secext2-*]. The structure of the 83 algorithm specific portion of the RDATA part of such RRs is as shown 84 below. 86 Field Size 87 ----- ---- 88 exponent length 1 or 3 octets (see text) 89 exponent as specified by length field 90 modulus remaining space 92 For interoperability, the exponent and modulus are each currently 93 limited to 4096 bits in length. The public key exponent is a 94 variable length unsigned integer. Its length in octets is 95 represented as one octet if it is in the range of 1 to 255 and by a 96 zero octet followed by a two octet unsigned length if it is longer 97 than 255 bytes. The public key modulus field is a multiprecision 98 unsigned integer. The length of the modulus can be determined from 99 the RDLENGTH and the preceding RDATA fields including the exponent. 100 Leading zero octets are prohibited in the exponent and modulus. 102 3. RSA/MD5 SIG Resource Records 104 The signature portion of the SIG RR RDATA area, when using the 105 RSA/MD5 algorithm, is calculated as shown below. The data signed is 106 determined as specified in [draft-ietf-dnssec-secext2-*]. See 107 [draft-ietf-dnssec-secext2-*] for fields in the SIG RR RDATA which 108 precede the signature itself. 110 hash = MD5 ( data ) 112 signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n) 114 where MD5 is the message digest algorithm documented in [RFC 1321], 115 "|" is concatenation, "e" is the private key exponent of the signer, 116 and "n" is the modulus of the signer's public key. 01, FF, and 00 117 are fixed octets of the corresponding hexadecimal value. "prefix" is 118 the ASN.1 BER MD5 algorithm designator prefix specified in PKCS1, 119 that is, 121 hex 3020300c06082a864886f70d020505000410 [NETSEC]. 123 This prefix is included to make it easier to use RSAREF (or similar 124 packages such as EuroRef). The FF octet MUST be repeated the maximum 125 number of times such that the value of the quantity being 126 exponentiated is one octet shorter than the value of n. 128 (The above specifications are identical to the corresponding part of 129 Public Key Cryptographic Standard #1 [PKCS1].) 131 The size of n, including most and least significant bits (which will 132 be 1) MUST be not less than 512 bits and not more than 4096 bits. n 133 and e SHOULD be chosen such that the public exponent is small. 135 Leading zero bytes are permitted in the RSA/MD5 algorithm signature. 137 A public exponent of 3 minimizes the effort needed to verify a 138 signature. Use of 3 as the public exponent is weak for 139 confidentiality uses since, if the same data can be collected 140 encrypted under three different keys with an exponent of 3 then, 141 using the Chinese Remainder Theorem [NETSEC], the original plain text 142 can be easily recovered. This weakness is not significant for DNS 143 security because we seek only authentication, not confidentiality. 145 4. Performance Considerations 147 General signature generation speeds are roughly the same for RSA and 148 DSA [RFC xDSA]. With sufficient pre-computation, signature 149 generation with DSA is faster than RSA. Key generation is also 150 faster for DSA. However, signature verification is an order of 151 magnitude slower with DSA when the RSA public exponent is chosen to 152 be small as is recommended for KEY RRs used in domain name system 153 (DNS) data authentication. 155 Current DNS implementations are optimized for small transfers, 156 typically less than 512 bytes including overhead. While larger 157 transfers will perform correctly and work is underway to make larger 158 transfers more efficient, it is still advisable at this time to make 159 reasonable efforts to minimize the size of KEY RR sets stored within 160 the DNS consistent with adequate security. Keep in mind that in a 161 secure zone, at least one authenticating SIG RR will also be 162 returned. 164 5. Security Considerations 166 Many of the general security consideration in [draft-ietf-dnssec- 167 secext2-*] apply. Keys retrieved from the DNS should not be trusted 168 unless (1) they have been securely obtained from a secure resolver or 169 independently verified by the user and (2) this secure resolver and 170 secure obtainment or independent verification conform to security 171 policies acceptable to the user. As with all cryptographic 172 algorithms, evaluating the necessary strength of the key is essential 173 and dependent on local policy. 175 For interoperability, the RSA key size is limited to 4096 bits. For 176 particularly critical applications, implementors are encouraged to 177 consider the range of available algorithms and key sizes. 179 References 181 [NETSEC] - Network Security: PRIVATE Communications in a PUBLIC 182 World, Charlie Kaufman, Radia Perlman, & Mike Speciner, Prentice Hall 183 Series in Computer Networking and Distributed Communications, 1995. 185 [PKCS1] - PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., 186 3 June 1991, Version 1.4. [there is an ID on this and any resulting 187 RFC could be substitutes if available in time] 189 [RFC 1034] - P. Mockapetris, "Domain names - concepts and 190 facilities", 11/01/1987. 192 [RFC 1035] - P. Mockapetris, "Domain names - implementation and 193 specification", 11/01/1987. 195 [RFC 1321] - R. Rivest, "The MD5 Message-Digest Algorithm", April 196 1992. 198 [draft-ietf-dnssec-secext2-*] - Domain Name System Security 199 Extensions, D. Eastlake, C. Kaufman, January 1997. 201 [RFC xDSA] - draft-ietf-dnssec-dss-*.txt 203 [Schneier] - Bruce Schneier, "Applied Cryptography Second Edition: 204 protocols, algorithms, and source code in C", 1996, John Wiley and 205 Sons, ISBN 0-471-11709-9. 207 Author's Address 209 Donald E. Eastlake 3rd 210 IBM 211 318 Acton Street 212 Carlisle, MA 01741 USA 214 Telephone: +1-978-287-4877 215 +1-914-784-7913 216 FAX: +1-978-371-7148 217 EMail: dee3@us.ibm.com 219 Expiration and File Name 221 This draft expires in April 1999. 223 Its file name is draft-ietf-dnssec-rsa-01.txt.