idnits 2.17.1 draft-ietf-dnsext-dnssec-rsasha256-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 345. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 352. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 358. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 106: '...RSA/SHA-256 keys MUST NOT be less than...' RFC 2119 keyword, line 107: '... MUST NOT be more than 4096 bits....' RFC 2119 keyword, line 114: '...RSA/SHA-512 keys MUST NOT be less than...' RFC 2119 keyword, line 115: '... and MUST NOT be more than 4096 bits...' RFC 2119 keyword, line 134: '...y. The FF octet MUST be repeated the ...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 11, 2008) is 5856 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) -- Looks like a reference, but probably isn't: 'Mnemonic' on line 211 ** Obsolete normative reference: RFC 3447 (ref. '4') (Obsoleted by RFC 8017) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Obsolete informational reference (is this intentional?): RFC 4641 (ref. '10') (Obsoleted by RFC 6781) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions working group J. Jansen 3 Internet-Draft NLnet Labs 4 Intended status: Standards Track April 11, 2008 5 Expires: October 13, 2008 7 Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records 8 for DNSSEC 9 draft-ietf-dnsext-dnssec-rsasha256-04 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 13, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document describes how to produce RSA/SHA-256 and RSA/SHA-512 43 DNSKEY and RRSIG resource records for use in the Domain Name System 44 Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3 50 2.1. RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . 3 51 2.2. RSA/SHA-512 DNSKEY Resource Records . . . . . . . . . . . . 3 52 3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . . 4 53 3.1. RSA/SHA-256 RRSIG Resource Records . . . . . . . . . . . . 4 54 3.2. RSA/SHA-512 RRSIG Resource Records . . . . . . . . . . . . 4 55 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 5 56 4.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Implementation Considerations . . . . . . . . . . . . . . . . . 5 59 5.1. Support for SHA-1 and SHA-2 signatures . . . . . . . . . . 5 60 5.2. Support for NSEC3 denial of existence . . . . . . . . . . . 5 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 7.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource 64 Records . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7.2. Signature Type Downgrade Attacks . . . . . . . . . . . . . 6 66 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 69 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 Intellectual Property and Copyright Statements . . . . . . . . . . 9 73 1. Introduction 75 The Domain Name System (DNS) is the global hierarchical distributed 76 database for Internet Addressing. The DNS has been extended to use 77 cryptographic keys and digital signatures for the verification of the 78 integrity of its data. RFC 4033 [1], RFC 4034 [2], and RFC 4035 [3] 79 describe these DNS Security Extensions, called DNSSEC. 81 RFC 4034 describes how to store DNSKEY and RRSIG resource records, 82 and specifies a list of cryptographic algorithms to use. This 83 document extends that list with the algorithms RSA/SHA-256 and RSA/ 84 SHA-512, and specifies how to store DNSKEY data and how to produce 85 RRSIG resource records with these hash algorithms. 87 Familiarity with DNSSEC, RSA [8] and the SHA-2 [5] family of 88 algorithms is assumed in this document. 90 To refer to both SHA-256 and SHA-512, this document will use the name 91 SHA-2. This is done to improve readability. When a part of text is 92 specific for either SHA-256 or SHA-512, their specific names are 93 used. The same goes for RSA/SHA-256 and RSA/SHA-512, which will be 94 grouped using the name RSA/SHA-2. 96 2. DNSKEY Resource Records 98 The format of the DNSKEY RR can be found in RFC 4034 [2] and RFC 3110 99 [6]. 101 2.1. RSA/SHA-256 DNSKEY Resource Records 103 RSA public keys for use with RSA/SHA-256 are stored in DNSKEY 104 resource records (RRs) with the algorithm number {TBA1}. 106 The key size for RSA/SHA-256 keys MUST NOT be less than 512 bits, and 107 MUST NOT be more than 4096 bits. 109 2.2. RSA/SHA-512 DNSKEY Resource Records 111 RSA public keys for use with RSA/SHA-512 are stored in DNSKEY 112 resource records (RRs) with the algorithm number {TBA2}. 114 The key size for RSA/SHA-512 keys MUST NOT be less than 1024 bits, 115 and MUST NOT be more than 4096 bits. 117 3. RRSIG Resource Records 119 The value of the signature field in the RRSIG RR follow the RSASSA- 120 PKCS1-v1_5 signature scheme, and is calculated as follows. The 121 values for the RDATA fields that precede the signature data are 122 specified in RFC 4034 [2]. 124 hash = SHA-XXX(data) 126 Where XXX is either 256 or 512, depending on the algorithm used. 128 signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) 130 Where SHA-XXX is the message digest algorithm as specified in FIPS 131 PUB 180-2 [5], "|" is concatenation, "00", "01", "FF" and "00" are 132 fixed octets of corresponding hexadecimal value, "e" is the private 133 exponent of the signing RSA key, and "n" is the public modulus of the 134 signing key. The FF octet MUST be repeated the maximum number of 135 times so that the total length of the signature equals the length of 136 the modulus of the signer's public key ("n"). "data" is the data of 137 the resource record set that is signed, as specified in RFC 4034 [2]. 139 The "prefix" is intended to make the use of standard cryptographic 140 libraries easier. These specifications are taken directly from the 141 specification of EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 section 9.2 142 [4]. The prefixes for the different algorithms are specified below. 144 3.1. RSA/SHA-256 RRSIG Resource Records 146 RSA/SHA-256 signatures are stored in the DNS using RRSIG resource 147 records (RRs) with algorithm number {TBA1}. 149 The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as 150 specified in PKCS #1 v2.1 [4]: 152 hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 154 3.2. RSA/SHA-512 RRSIG Resource Records 156 RSA/SHA-512 signatures are stored in the DNS using RRSIG resource 157 records (RRs) with algorithm number {TBA2}. 159 The prefix is the ASN.1 BER SHA-512 algorithm designator prefix as 160 specified in PKCS #1 v2.1 [4]: 162 hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40 164 4. Deployment Considerations 166 4.1. Key Sizes 168 Apart from prohibiting RSA/SHA-512 signatures smaller than 1024 169 bytes, this document will not specify what size of keys to use. That 170 is an operational issue and depends largely on the environment and 171 intended use. Some good starting points for more information might 172 be DNSSEC Operational Practises [10], section 3.5, and NIST SP 800-57 173 Part 1 [11] and Part 3 [12]. 175 4.2. Signature Sizes 177 In this family of signing algorithms, the size of signatures is 178 related to the size of the key, and not the hashing algorithm used in 179 the signing process. Therefore, RRSIG resource records produced with 180 RSA/SHA256 or RSA/SHA512 shall have the same size as those produced 181 with RSA/SHA1, if the keys have the same length. 183 5. Implementation Considerations 185 5.1. Support for SHA-1 and SHA-2 signatures 187 DNSSEC aware implementations SHOULD be able to support RRSIG resource 188 records with the RSA/SHA-2 algorithms. 190 If both RSA/SHA-2 and RSA/SHA-1 RRSIG resource records are available 191 for a certain RRset, with a secure path to their keys, the validator 192 SHOULD ignore the SHA-1 signature. If the RSA/SHA-2 signature does 193 not verify the data, and the RSA/SHA-1 signature does, the validator 194 SHOULD mark the data with the security status from the RSA/SHA-2 195 signature. 197 5.2. Support for NSEC3 denial of existence 199 Implementations that have support for RSA/SHA-2 MUST also have 200 support for NSEC3 denial of existence, as specified in RFC 5155 [7]. 202 6. IANA Considerations 204 IANA has not yet assigned an algorithm number for RSA/SHA-256 and 205 RSA/SHA-512. 207 The algorithm list from RFC 4034 Appendix A.1 [2] is extended with 208 the following entries: 210 Zone 211 Value Algorithm [Mnemonic] Signing References Status 212 ----- ----------- ----------- ------- ----------- -------- 213 {TBA1} RSA/SHA-256 RSASHA256 y {this memo} OPTIONAL 214 {TBA2} RSA/SHA-512 RSASHA512 y {this memo} OPTIONAL 216 7. Security Considerations 218 7.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource Records 220 Users of DNSSEC are encouraged to deploy SHA-2 as soon as software 221 implementations allow for it. SHA-2 is widely believed to be more 222 resilient to attack than SHA-1, and confidence in SHA-1's strength is 223 being eroded by recently-announced attacks. Regardless of whether or 224 not the attacks on SHA-1 will affect DNSSEC, it is believed (at the 225 time of this writing) that SHA-2 is the better choice for use in 226 DNSSEC records. 228 SHA-2 is considered sufficiently strong for the immediate future, but 229 predictions about future development in cryptography and 230 cryptanalysis are beyond the scope of this document. 232 The signature scheme RSASSA-PKCS1-v1_5 is chosen to match the one 233 used for RSA/SHA-1 signatures. This should ease implementation of 234 the new hashing algorithms in DNSSEC software. 236 7.2. Signature Type Downgrade Attacks 238 Since each RRset MUST be signed with each algorithm present in the 239 DNSKEY RRset at the zone apex (see [3] Section 2.2), a malicious 240 party cannot filter out the RSA/SHA-2 RRSIG, and force the validator 241 to use the RSA/SHA-1 signature if both are present in the zone. 242 Together with the implementation considerations from Section 5 of 243 this document, this provides resilience against algorithm downgrade 244 attacks, if the validator supports RSA/SHA-2. 246 8. Acknowledgments 248 This document is a minor extension to RFC 4034 [2]. Also, we try to 249 follow the documents RFC 3110 [6] and RFC 4509 [9] for consistency. 250 The authors of and contributors to these documents are gratefully 251 acknowledged for their hard work. 253 The following people provided additional feedback and text: Jaap 254 Akkerhuis, Roy Arends, Rob Austein, Miek Gieben, Alfred Hoenes, 255 Michael St. Johns, Scott Rose and Wouter Wijngaards. 257 9. References 259 9.1. Normative References 261 [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 262 "DNS Security Introduction and Requirements", RFC 4033, 263 March 2005. 265 [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 266 "Resource Records for the DNS Security Extensions", RFC 4034, 267 March 2005. 269 [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 270 "Protocol Modifications for the DNS Security Extensions", 271 RFC 4035, March 2005. 273 [4] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards 274 (PKCS) #1: RSA Cryptography Specifications Version 2.1", 275 RFC 3447, February 2003. 277 [5] National Institute of Standards and Technology, "Secure Hash 278 Standard", FIPS PUB 180-2, August 2002. 280 [6] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 281 System (DNS)", RFC 3110, May 2001. 283 [7] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 284 Security (DNSSEC) Hashed Authenticated Denial of Existence", 285 RFC 5155, March 2008. 287 9.2. Informative References 289 [8] Schneier, B., "Applied Cryptography Second Edition: protocols, 290 algorithms, and source code in C", Wiley and Sons , ISBN 0-471- 291 11709-9, 1996. 293 [9] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) 294 Resource Records (RRs)", RFC 4509, May 2006. 296 [10] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 297 RFC 4641, September 2006. 299 [11] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, 300 "Recommendations for Key Management Part 1: General", NIST 301 SP 800-57 Part 1, March 2007. 303 [12] Barker, E., Barker, W., Burr, W., Jones, A., Polk, W., Smid, 304 M., and S. Rose, "Recommendations for Key Management Part 3: 306 Application-Specific Key Guidance", NIST SP 800-57 Part 3, 307 March 2007. 309 Author's Address 311 Jelte Jansen 312 NLnet Labs 313 Kruislaan 419 314 Amsterdam 1098VA 315 NL 317 Email: jelte@NLnetLabs.nl 318 URI: http://www.nlnetlabs.nl/ 320 Full Copyright Statement 322 Copyright (C) The IETF Trust (2008). 324 This document is subject to the rights, licenses and restrictions 325 contained in BCP 78, and except as set forth therein, the authors 326 retain all their rights. 328 This document and the information contained herein are provided on an 329 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 330 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 331 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 332 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 333 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 334 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 336 Intellectual Property 338 The IETF takes no position regarding the validity or scope of any 339 Intellectual Property Rights or other rights that might be claimed to 340 pertain to the implementation or use of the technology described in 341 this document or the extent to which any license under such rights 342 might or might not be available; nor does it represent that it has 343 made any independent effort to identify any such rights. Information 344 on the procedures with respect to rights in RFC documents can be 345 found in BCP 78 and BCP 79. 347 Copies of IPR disclosures made to the IETF Secretariat and any 348 assurances of licenses to be made available, or the result of an 349 attempt made to obtain a general license or permission for the use of 350 such proprietary rights by implementers or users of this 351 specification can be obtained from the IETF on-line IPR repository at 352 http://www.ietf.org/ipr. 354 The IETF invites any interested party to bring to its attention any 355 copyrights, patents or patent applications, or other proprietary 356 rights that may cover technology that may be required to implement 357 this standard. Please address the information to the IETF at 358 ietf-ipr@ietf.org. 360 Acknowledgment 362 Funding for the RFC Editor function is provided by the IETF 363 Administrative Support Activity (IASA).