idnits 2.17.1 draft-ietf-dnsext-dnssec-rsasha256-07.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 : ---------------------------------------------------------------------------- No issues found here. 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 (December 03, 2008) is 5617 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) -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 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 December 03, 2008 5 Expires: June 6, 2009 7 Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records 8 for DNSSEC 9 draft-ietf-dnsext-dnssec-rsasha256-07 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 June 6, 2009. 36 Abstract 38 This document describes how to produce RSA/SHA-256 and RSA/SHA-512 39 DNSKEY and RRSIG resource records for use in the Domain Name System 40 Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3 46 2.1. RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . 3 47 2.2. RSA/SHA-512 DNSKEY Resource Records . . . . . . . . . . . . 4 48 3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . . 4 49 3.1. RSA/SHA-256 RRSIG Resource Records . . . . . . . . . . . . 4 50 3.2. RSA/SHA-512 RRSIG Resource Records . . . . . . . . . . . . 5 51 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 5 52 4.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 4.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 5 54 5. Implementation Considerations . . . . . . . . . . . . . . . . . 5 55 5.1. Support for SHA-2 signatures . . . . . . . . . . . . . . . 5 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 58 7.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource 59 Records . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 7.2. Signature Type Downgrade Attacks . . . . . . . . . . . . . 6 61 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 64 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 Intellectual Property and Copyright Statements . . . . . . . . . . 9 68 1. Introduction 70 The Domain Name System (DNS) is the global hierarchical distributed 71 database for Internet Naming. The DNS has been extended to use 72 cryptographic keys and digital signatures for the verification of the 73 authenticity and integrity of its data. RFC 4033 [RFC4033], RFC 4034 74 [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security 75 Extensions, called DNSSEC. 77 RFC 4034 describes how to store DNSKEY and RRSIG resource records, 78 and specifies a list of cryptographic algorithms to use. This 79 document extends that list with the algorithms RSA/SHA-256 and RSA/ 80 SHA-512, and specifies how to store DNSKEY data and how to produce 81 RRSIG resource records with these hash algorithms. 83 Familiarity with DNSSEC, RSA and the SHA-2 [FIPS.180-2.2002] family 84 of algorithms is assumed in this document. 86 To refer to both SHA-256 and SHA-512, this document will use the name 87 SHA-2. This is done to improve readability. When a part of text is 88 specific for either SHA-256 or SHA-512, their specific names are 89 used. The same goes for RSA/SHA-256 and RSA/SHA-512, which will be 90 grouped using the name RSA/SHA-2. 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. DNSKEY Resource Records 98 The format of the DNSKEY RR can be found in RFC 4034 [RFC4034]. RFC 99 3110 [RFC3110] describes the use of RSA/SHA-1 for DNSSEC signatures. 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 For use with NSEC3 [RFC5155], the algorithm number for RSA/SHA-256 107 will be {TBA2}. The use of a different algorithm number to 108 differentiate between the use of NSEC and NSEC3 is in keeping with 109 the approach adopted in RFC5155. 111 For interoperability, as in RFC 3110 [RFC3110], the key size of RSA/ 112 SHA-256 keys MUST NOT be less than 512 bits, and MUST NOT be more 113 than 4096 bits. 115 2.2. RSA/SHA-512 DNSKEY Resource Records 117 RSA public keys for use with RSA/SHA-512 are stored in DNSKEY 118 resource records (RRs) with the algorithm number {TBA3}. 120 For use with NSEC3, the algorithm number for RSA/SHA-512 will be 121 {TBA4}. The use of a different algorithm number to differentiate 122 between the use of NSEC and NSEC3 is in keeping with the approach 123 adopted in RFC5155. 125 The key size of RSA/SHA-512 keys MUST NOT be less than 1024 bits, and 126 MUST NOT be more than 4096 bits. 128 3. RRSIG Resource Records 130 The value of the signature field in the RRSIG RR follows the RSASSA- 131 PKCS1-v1_5 signature scheme, and is calculated as follows. The 132 values for the RDATA fields that precede the signature data are 133 specified in RFC 4034 [RFC4034]. 135 hash = SHA-XXX(data) 137 Here XXX is either 256 or 512, depending on the algorithm used, as 138 specified in FIPS PUB 180-2 [FIPS.180-2.2002], and "data" is the wire 139 format data of the resource record set that is signed, as specified 140 in RFC 4034 [RFC4034]. 142 signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) 144 Here "|" is concatenation, "00", "01", "FF" and "00" are fixed octets 145 of corresponding hexadecimal value, "e" is the private exponent of 146 the signing RSA key, and "n" is the public modulus of the signing 147 key. The FF octet MUST be repeated the exact number of times so that 148 the total length of the concatenated term in parentheses equals the 149 length of the modulus of the signer's public key ("n"). 151 The "prefix" is intended to make the use of standard cryptographic 152 libraries easier. These specifications are taken directly from the 153 specifications of RSASSA-PKCS1-v1_5 in PKCS #1 v2.1 section 8.2 154 [RFC3447], and EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 section 9.2 155 [RFC3447]. The prefixes for the different algorithms are specified 156 below. 158 3.1. RSA/SHA-256 RRSIG Resource Records 160 RSA/SHA-256 signatures are stored in the DNS using RRSIG resource 161 records (RRs) with algorithm number {TBA1} for use with NSEC, or 162 {TBA2} for use with NSEC3. 164 The prefix is the ASN.1 DER SHA-256 algorithm designator prefix as 165 specified in PKCS #1 v2.1 [RFC3447]: 167 hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 169 3.2. RSA/SHA-512 RRSIG Resource Records 171 RSA/SHA-512 signatures are stored in the DNS using RRSIG resource 172 records (RRs) with algorithm number {TBA3} for use with NSEC, or 173 {TBA4} for use with NSEC3. 175 The prefix is the ASN.1 DER SHA-512 algorithm designator prefix as 176 specified in PKCS #1 v2.1 [RFC3447]: 178 hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40 180 4. Deployment Considerations 182 4.1. Key Sizes 184 Apart from the restrictions specified in section 2, this document 185 will not specify what size of keys to use. That is an operational 186 issue and depends largely on the environment and intended use. A 187 good starting point for more information would be NIST SP 800-57 188 [NIST800-57]. 190 4.2. Signature Sizes 192 In this family of signing algorithms, the size of signatures is 193 related to the size of the key, and not the hashing algorithm used in 194 the signing process. Therefore, RRSIG resource records produced with 195 RSA/SHA256 or RSA/SHA512 will have the same size as those produced 196 with RSA/SHA1, if the keys have the same length. 198 5. Implementation Considerations 200 5.1. Support for SHA-2 signatures 202 DNSSEC aware implementations SHOULD be able to support RRSIG resource 203 records with the RSA/SHA-2 algorithms. 205 6. IANA Considerations 207 Note to the RFC editor: please remove this paragraph during final 208 editing, and request IANA to update the {TBA} designators. 210 IANA has assigned DNS Security Algorithm Numbers {TBA1} for RSA/ 211 SHA-256 with NSEC, {TBA2} for RSA/SHA-256 with NSEC3, {TBA3} for RSA/ 212 SHA-512 with NSEC, and {TBA4} for RSA/SHA-512 with NSEC3. 214 The algorithm list from RFC 4034 Appendix A.1 [RFC4034] is extended 215 with the following entries: 217 Zone 218 Value Algorithm Mnemonic Signing References 219 {TBA1} RSA/SHA-256 RSASHA256 y {this memo} 220 {TBA2} RSA/SHA-256-NSEC3 RSASHA256NSEC3 y {this memo} 221 {TBA3} RSA/SHA-512 RSASHA512 y {this memo} 222 {TBA4} RSA/SHA-512-NSEC3 RSASHA512NSEC3 y {this memo} 224 7. Security Considerations 226 7.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource Records 228 Users of DNSSEC are encouraged to deploy SHA-2 as soon as software 229 implementations allow for it. SHA-2 is widely believed to be more 230 resilient to attack than SHA-1, and confidence in SHA-1's strength is 231 being eroded by recently-announced attacks. Regardless of whether or 232 not the attacks on SHA-1 will affect DNSSEC, it is believed (at the 233 time of this writing) that SHA-2 is the better choice for use in 234 DNSSEC records. 236 SHA-2 is considered sufficiently strong for the immediate future, but 237 predictions about future development in cryptography and 238 cryptanalysis are beyond the scope of this document. 240 The signature scheme RSASSA-PKCS1-v1_5 is chosen to match the one 241 used for RSA/SHA-1 signatures. This should ease implementation of 242 the new hashing algorithms in DNSSEC software. 244 7.2. Signature Type Downgrade Attacks 246 Since each RRSet MUST be signed with each algorithm present in the 247 DNSKEY RRSet at the zone apex (see [RFC4035] Section 2.2), a 248 malicious party cannot filter out the RSA/SHA-2 RRSIG, and force the 249 validator to use the RSA/SHA-1 signature if both are present in the 250 zone. This should provide resilience against algorithm downgrade 251 attacks, if the validator supports RSA/SHA-2. 253 8. Acknowledgments 255 This document is a minor extension to RFC 4034 [RFC4034]. Also, we 256 try to follow the documents RFC 3110 [RFC3110] and RFC 4509 [RFC4509] 257 for consistency. The authors of and contributors to these documents 258 are gratefully acknowledged for their hard work. 260 The following people provided additional feedback and text: Jaap 261 Akkerhuis, Roy Arends, Rob Austein, Francis Dupont, Miek Gieben, 262 Alfred Hoenes, Paul Hoffman, Peter Koch, Michael St. Johns, Scott 263 Rose and Wouter Wijngaards. 265 9. References 267 9.1. Normative References 269 [FIPS.180-2.2002] 270 National Institute of Standards and Technology, "Secure 271 Hash Standard", FIPS PUB 180-2, August 2002. 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", RFC 2119, March 1997. 276 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 277 Name System (DNS)", RFC 3110, May 2001. 279 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 280 Rose, "DNS Security Introduction and Requirements", 281 RFC 4033, March 2005. 283 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 284 Rose, "Resource Records for the DNS Security Extensions", 285 RFC 4034, March 2005. 287 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 288 Rose, "Protocol Modifications for the DNS Security 289 Extensions", RFC 4035, March 2005. 291 9.2. Informative References 293 [NIST800-57] 294 Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, 295 "Recommendations for Key Management", NIST SP 800-57, 296 March 2007. 298 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 299 Standards (PKCS) #1: RSA Cryptography Specifications 300 Version 2.1", RFC 3447, February 2003. 302 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 303 (DS) Resource Records (RRs)", RFC 4509, May 2006. 305 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 306 Security (DNSSEC) Hashed Authenticated Denial of 307 Existence", RFC 5155, March 2008. 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.