idnits 2.17.1 draft-ietf-dnsext-dnssec-rsasha256-06.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 324. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 348. 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 108: '... SHA-256 keys MUST NOT be less than ...' RFC 2119 keyword, line 121: '...RSA/SHA-512 keys MUST NOT be less than...' RFC 2119 keyword, line 122: '... MUST NOT be more than 4096 bits....' RFC 2119 keyword, line 143: '...y. The FF octet MUST be repeated the ...' RFC 2119 keyword, line 198: '... implementations SHOULD be able to sup...' (1 more instance...) 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 (October 23, 2008) is 5664 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) == Missing Reference: 'Mnemonic' is mentioned on line 211, but not defined -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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 October 23, 2008 5 Expires: April 26, 2009 7 Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records 8 for DNSSEC 9 draft-ietf-dnsext-dnssec-rsasha256-06 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 April 26, 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 . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 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 2. DNSKEY Resource Records 94 The format of the DNSKEY RR can be found in RFC 4034 [RFC4034], RFC 95 3110 [RFC3110] describes the use of RSA/SHA-1 for DNSSEC signatures. 97 2.1. RSA/SHA-256 DNSKEY Resource Records 99 RSA public keys for use with RSA/SHA-256 are stored in DNSKEY 100 resource records (RRs) with the algorithm number {TBA1}. 102 For use with NSEC3 [RFC5155], the algorithm number for RSA/SHA-256 103 will be {TBA2}. The use of a different algorithm number to 104 differentiate between the use of NSEC and NSEC3 is in keeping with 105 the approach adopted in RFC5155. 107 For interoperability, as in RFC 3110 [RFC3110], the key size of RSA/ 108 SHA-256 keys MUST NOT be less than 512 bits, and MUST NOT be more 109 than 4096 bits. 111 2.2. RSA/SHA-512 DNSKEY Resource Records 113 RSA public keys for use with RSA/SHA-512 are stored in DNSKEY 114 resource records (RRs) with the algorithm number {TBA3}. 116 For use with NSEC3, the algorithm number for RSA/SHA-512 will be 117 {TBA4}. The use of a different algorithm number to differentiate 118 between the use of NSEC and NSEC3 is in keeping with the approach 119 adopted in RFC5155. 121 The key size of RSA/SHA-512 keys MUST NOT be less than 1024 bits, and 122 MUST NOT be more than 4096 bits. 124 3. RRSIG Resource Records 126 The value of the signature field in the RRSIG RR follows the RSASSA- 127 PKCS1-v1_5 signature scheme, and is calculated as follows. The 128 values for the RDATA fields that precede the signature data are 129 specified in RFC 4034 [RFC4034]. 131 hash = SHA-XXX(data) 133 Here XXX is either 256 or 512, depending on the algorithm used, as 134 specified in FIPS PUB 180-2 [FIPS.180-2.2002], and "data" is the wire 135 format data of the resource record set that is signed, as specified 136 in RFC 4034 [RFC4034]. 138 signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) 140 Here "|" is concatenation, "00", "01", "FF" and "00" are fixed octets 141 of corresponding hexadecimal value, "e" is the private exponent of 142 the signing RSA key, and "n" is the public modulus of the signing 143 key. The FF octet MUST be repeated the exact number of times so that 144 the total length of the concatenated term in parentheses equals the 145 length of the modulus of the signer's public key ("n"). 147 The "prefix" is intended to make the use of standard cryptographic 148 libraries easier. These specifications are taken directly from the 149 specifications of RSASSA-PKCS1-v1_5 in PKCS #1 v2.1 section 8.2 150 [RFC3447], and EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 section 9.2 151 [RFC3447]. The prefixes for the different algorithms are specified 152 below. 154 3.1. RSA/SHA-256 RRSIG Resource Records 156 RSA/SHA-256 signatures are stored in the DNS using RRSIG resource 157 records (RRs) with algorithm number {TBA1} for use with NSEC, or 158 {TBA2} for use with NSEC3. 160 The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as 161 specified in PKCS #1 v2.1 [RFC3447]: 163 hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 165 3.2. RSA/SHA-512 RRSIG Resource Records 167 RSA/SHA-512 signatures are stored in the DNS using RRSIG resource 168 records (RRs) with algorithm number {TBA3} for use with NSEC, or 169 {TBA4} for use with NSEC3. 171 The prefix is the ASN.1 BER SHA-512 algorithm designator prefix as 172 specified in PKCS #1 v2.1 [RFC3447]: 174 hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40 176 4. Deployment Considerations 178 4.1. Key Sizes 180 Apart from the restrictions specified in section 2, this document 181 will not specify what size of keys to use. That is an operational 182 issue and depends largely on the environment and intended use. A 183 good starting point for more information would be NIST SP 800-57 184 [NIST800-57]. 186 4.2. Signature Sizes 188 In this family of signing algorithms, the size of signatures is 189 related to the size of the key, and not the hashing algorithm used in 190 the signing process. Therefore, RRSIG resource records produced with 191 RSA/SHA256 or RSA/SHA512 will have the same size as those produced 192 with RSA/SHA1, if the keys have the same length. 194 5. Implementation Considerations 196 5.1. Support for SHA-2 signatures 198 DNSSEC aware implementations SHOULD be able to support RRSIG resource 199 records with the RSA/SHA-2 algorithms. 201 6. IANA Considerations 203 IANA has assigned DNS Security Algorithm Numbers {TBA1} for RSA/ 204 SHA-256 with NSEC, {TBA2} for RSA/SHA-256 with NSEC3, {TBA3} for RSA/ 205 SHA-512 with NSEC, and {TBA4} for RSA/SHA-512 with NSEC3. 207 The algorithm list from RFC 4034 Appendix A.1 [RFC4034] is extended 208 with the following entries: 210 Zone 211 Value Algorithm [Mnemonic] Signing References 212 {TBA1} RSA/SHA-256 RSASHA256 y {this memo} 213 {TBA2} RSA/SHA-256-NSEC3 RSASHA256NSEC3 y {this memo} 214 {TBA3} RSA/SHA-512 RSASHA512 y {this memo} 215 {TBA4} RSA/SHA-512-NSEC3 RSASHA512NSEC3 y {this memo} 217 7. Security Considerations 219 7.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource Records 221 Users of DNSSEC are encouraged to deploy SHA-2 as soon as software 222 implementations allow for it. SHA-2 is widely believed to be more 223 resilient to attack than SHA-1, and confidence in SHA-1's strength is 224 being eroded by recently-announced attacks. Regardless of whether or 225 not the attacks on SHA-1 will affect DNSSEC, it is believed (at the 226 time of this writing) that SHA-2 is the better choice for use in 227 DNSSEC records. 229 SHA-2 is considered sufficiently strong for the immediate future, but 230 predictions about future development in cryptography and 231 cryptanalysis are beyond the scope of this document. 233 The signature scheme RSASSA-PKCS1-v1_5 is chosen to match the one 234 used for RSA/SHA-1 signatures. This should ease implementation of 235 the new hashing algorithms in DNSSEC software. 237 7.2. Signature Type Downgrade Attacks 239 Since each RRSet MUST be signed with each algorithm present in the 240 DNSKEY RRSet at the zone apex (see [RFC4035] Section 2.2), a 241 malicious party cannot filter out the RSA/SHA-2 RRSIG, and force the 242 validator to use the RSA/SHA-1 signature if both are present in the 243 zone. This should provide 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 [RFC4034]. Also, we 249 try to follow the documents RFC 3110 [RFC3110] and RFC 4509 [RFC4509] 250 for consistency. The authors of and contributors to these documents 251 are gratefully acknowledged for their hard work. 253 The following people provided additional feedback and text: Jaap 254 Akkerhuis, Roy Arends, Rob Austein, Francis Dupont, Miek Gieben, 255 Alfred Hoenes, Paul Hoffman, Peter Koch, Michael St. Johns, Scott 256 Rose and Wouter Wijngaards. 258 9. References 260 9.1. Normative References 262 [FIPS.180-2.2002] 263 National Institute of Standards and Technology, "Secure 264 Hash Standard", FIPS PUB 180-2, August 2002. 266 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 267 Name System (DNS)", RFC 3110, May 2001. 269 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 270 Rose, "DNS Security Introduction and Requirements", 271 RFC 4033, March 2005. 273 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 274 Rose, "Resource Records for the DNS Security Extensions", 275 RFC 4034, March 2005. 277 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 278 Rose, "Protocol Modifications for the DNS Security 279 Extensions", RFC 4035, March 2005. 281 9.2. Informative References 283 [NIST800-57] 284 Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, 285 "Recommendations for Key Management", NIST SP 800-57, 286 March 2007. 288 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 289 Standards (PKCS) #1: RSA Cryptography Specifications 290 Version 2.1", RFC 3447, February 2003. 292 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 293 (DS) Resource Records (RRs)", RFC 4509, May 2006. 295 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 296 Security (DNSSEC) Hashed Authenticated Denial of 297 Existence", RFC 5155, March 2008. 299 Author's Address 301 Jelte Jansen 302 NLnet Labs 303 Kruislaan 419 304 Amsterdam 1098VA 305 NL 307 Email: jelte@NLnetLabs.nl 308 URI: http://www.nlnetlabs.nl/ 310 Full Copyright Statement 312 Copyright (C) The IETF Trust (2008). 314 This document is subject to the rights, licenses and restrictions 315 contained in BCP 78, and except as set forth therein, the authors 316 retain all their rights. 318 This document and the information contained herein are provided on an 319 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 320 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 321 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 322 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 323 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 324 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 326 Intellectual Property 328 The IETF takes no position regarding the validity or scope of any 329 Intellectual Property Rights or other rights that might be claimed to 330 pertain to the implementation or use of the technology described in 331 this document or the extent to which any license under such rights 332 might or might not be available; nor does it represent that it has 333 made any independent effort to identify any such rights. Information 334 on the procedures with respect to rights in RFC documents can be 335 found in BCP 78 and BCP 79. 337 Copies of IPR disclosures made to the IETF Secretariat and any 338 assurances of licenses to be made available, or the result of an 339 attempt made to obtain a general license or permission for the use of 340 such proprietary rights by implementers or users of this 341 specification can be obtained from the IETF on-line IPR repository at 342 http://www.ietf.org/ipr. 344 The IETF invites any interested party to bring to its attention any 345 copyrights, patents or patent applications, or other proprietary 346 rights that may cover technology that may be required to implement 347 this standard. Please address the information to the IETF at 348 ietf-ipr@ietf.org.