idnits 2.17.1 draft-ietf-dnsext-dnssec-rsasha256-03.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 354. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 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 117: '...RSA/SHA-512 keys MUST NOT be less than...' RFC 2119 keyword, line 118: '... and MUST NOT be more than 4096 bits...' RFC 2119 keyword, line 137: '...y. The FF octet MUST be repeated the ...' (8 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 (February 16, 2008) is 5914 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 209 ** 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. '9') (Obsoleted by RFC 6781) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 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 Expires: August 19, 2008 February 16, 2008 6 Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records 7 for DNSSEC 8 draft-ietf-dnsext-dnssec-rsasha256-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 19, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document describes how to produce RSA/SHA-256 and RSA/SHA-512 42 DNSKEY and RRSIG resource records for use in the Domain Name System 43 Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3 49 2.1. RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . 3 50 2.2. RSA/SHA-512 DNSKEY Resource Records . . . . . . . . . . . . 3 51 3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . . 4 52 3.1. RSA/SHA-256 RRSIG Resource Records . . . . . . . . . . . . 4 53 3.2. RSA/SHA-512 RRSIG Resource Records . . . . . . . . . . . . 4 54 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 5 55 4.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 5 57 5. Implementation Considerations . . . . . . . . . . . . . . . . . 5 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 7.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource 61 Records . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 7.2. Signature Type Downgrade Attacks . . . . . . . . . . . . . 6 63 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 66 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 Intellectual Property and Copyright Statements . . . . . . . . . . 9 70 1. Introduction 72 The Domain Name System (DNS) is the global hierarchical distributed 73 database for Internet Addressing. The DNS has been extended to use 74 cryptographic keys and digital signatures for the verification of the 75 integrity of its data. RFC 4033 [1], RFC 4034 [2], and RFC 4035 [3] 76 describe these DNS Security Extensions, called DNSSEC. 78 RFC 4034 describes how to store DNSKEY and RRSIG resource records, 79 and specifies a list of cryptographic algorithms to use. This 80 document extends that list with the algorithms RSA/SHA-256 and RSA/ 81 SHA-512, and specifies how to store DNSKEY data and how to produce 82 RRSIG resource records with these hash algorithms. 84 Familiarity with DNSSEC, RSA [7] and the SHA-2 [5] family of 85 algorithms is assumed in this document. 87 To refer to both SHA-256 and SHA-512, this document will use the name 88 SHA-2. This is done to improve readability. When a part of text is 89 specific for either SHA-256 or SHA-512, their specific names are 90 used. The same goes for RSA/SHA-256 and RSA/SHA-512, which will be 91 grouped using the name RSA/SHA-2. 93 2. DNSKEY Resource Records 95 The format of the DNSKEY RR can be found in RFC 4034 [2] and RFC 3110 96 [6]. 98 2.1. RSA/SHA-256 DNSKEY Resource Records 100 RSA public keys for use with RSA/SHA-256 are stored in DNSKEY 101 resource records (RRs) with the algorithm number {TBA1}. 103 For use with NSEC3, the algorithm number of RSA/SHA-256 will be 104 {TBA2}. 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 {TBA3}. 114 For use with NSEC3, the algorithm number of RSA/SHA-512 will be 115 {TBA4}. 117 The key size for RSA/SHA-512 keys MUST NOT be less than 1024 bits, 118 and MUST NOT be more than 4096 bits. 120 3. RRSIG Resource Records 122 The value of the signature field in the RRSIG RR follow the RSASSA- 123 PKCS1-v1_5 signature scheme, and is calculated as follows. The 124 values for the RDATA fields that precede the signature data are 125 specified in RFC 4034 [2]. 127 hash = SHA-XXX(data) 129 Where XXX is either 256 or 512, depending on the algorithm used. 131 signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) 133 Where SHA-XXX is the message digest algorithm as specified in FIPS 134 PUB 180-2 [5], "|" is concatenation, "00", "01", "FF" and "00" are 135 fixed octets of corresponding hexadecimal value, "e" is the private 136 exponent of the signing RSA key, and "n" is the public modulus of the 137 signing key. The FF octet MUST be repeated the maximum number of 138 times so that the total length of the signature equals the length of 139 the modulus of the signer's public key ("n"). "data" is the data of 140 the resource record set that is signed, as specified in RFC 4034 [2]. 142 The "prefix" is intended to make the use of standard cryptographic 143 libraries easier. These specifications are taken directly from the 144 specification of EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 section 9.2 145 [4]. The prefixes for the different algorithms are specified below. 147 3.1. RSA/SHA-256 RRSIG Resource Records 149 RSA/SHA-256 signatures are stored in the DNS using RRSIG resource 150 records (RRs) with algorithm number {TBA1} for use with NSEC, or 151 {TBA2} for use with NSEC3. 153 The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as 154 specified in PKCS #1 v2.1 [4]: 156 hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 158 3.2. RSA/SHA-512 RRSIG Resource Records 160 RSA/SHA-512 signatures are stored in the DNS using RRSIG resource 161 records (RRs) with algorithm number {TBA3} for use with NSEC, or 162 {TBA4} for use with NSEC3. 164 The prefix is the ASN.1 BER SHA-512 algorithm designator prefix as 165 specified in PKCS #1 v2.1 [4]: 167 hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40 169 4. Deployment Considerations 171 4.1. Key Sizes 173 Apart from prohibiting RSA/SHA-512 signatures smaller than 1024 174 bytes, this document will not specify what size of keys to use. That 175 is more an operational issue and depends largely on the environment 176 and intended use. Some good starting points might be DNSSEC 177 Operational Practises [9], section 3.5, and NIST SP 800-57 Part 1 178 [10] and Part 3 [11]. 180 4.2. Signature Sizes 182 In this family of signing algorithms, the size of signatures is 183 related to the size of the key, and not the hashing algorithm used in 184 the signing process. Therefore, RRSIG resource records produced with 185 RSA/SHA256 or RSA/SHA512 shall have the same size as those produced 186 with RSA/SHA1, if the keys have the same length. 188 5. Implementation Considerations 190 DNSSEC aware implementations SHOULD be able to support RRSIG resource 191 records with the RSA/SHA-2 algorithms. 193 If both RSA/SHA-2 and RSA/SHA-1 RRSIG resource records are available 194 for a certain RRset, with a secure path to their keys, the validator 195 SHOULD ignore the SHA-1 signature. If the RSA/SHA-2 signature does 196 not verify the data, and the RSA/SHA-1 signature does, the validator 197 SHOULD mark the data with the security status from the RSA/SHA-2 198 signature. 200 6. IANA Considerations 202 IANA has not yet assigned an algorithm number for RSA/SHA-256 and 203 RSA/SHA-512. 205 The algorithm list from RFC 4034 Appendix A.1 [2] is extended with 206 the following entries: 208 Zone 209 Value Algorithm [Mnemonic] Signing References Status 210 ----- ----------- ----------- ------- ----------- -------- 211 {TBA1} RSA/SHA-256 RSASHA256 y {this memo} OPTIONAL 212 {TBA2} RSA/SHA-256-NSEC3 RSASHA256NSEC3 y {this memo} OPTIONAL 213 {TBA3} RSA/SHA-512 RSASHA512 y {this memo} OPTIONAL 214 {TBA4} RSA/SHA-512-NSEC3 RSASHA512NSEC3 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 [8] 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 9.2. Informative References 285 [7] Schneier, B., "Applied Cryptography Second Edition: protocols, 286 algorithms, and source code in C", Wiley and Sons , ISBN 0-471- 287 11709-9, 1996. 289 [8] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) 290 Resource Records (RRs)", RFC 4509, May 2006. 292 [9] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 293 RFC 4641, September 2006. 295 [10] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, 296 "Recommendations for Key Management Part 1: General", NIST 297 SP 800-57 Part 1, March 2007. 299 [11] Barker, E., Barker, W., Burr, W., Jones, A., Polk, W., Smid, 300 M., and S. Rose, "Recommendations for Key Management Part 3: 302 Application-Specific Key Guidance", NIST SP 800-57 Part 3, 303 March 2007. 305 Author's Address 307 Jelte Jansen 308 NLnet Labs 309 Kruislaan 419 310 Amsterdam 1098VA 311 NL 313 Email: jelte@NLnetLabs.nl 314 URI: http://www.nlnetlabs.nl/ 316 Full Copyright Statement 318 Copyright (C) The IETF Trust (2008). 320 This document is subject to the rights, licenses and restrictions 321 contained in BCP 78, and except as set forth therein, the authors 322 retain all their rights. 324 This document and the information contained herein are provided on an 325 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 326 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 327 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 328 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 329 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 330 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 332 Intellectual Property 334 The IETF takes no position regarding the validity or scope of any 335 Intellectual Property Rights or other rights that might be claimed to 336 pertain to the implementation or use of the technology described in 337 this document or the extent to which any license under such rights 338 might or might not be available; nor does it represent that it has 339 made any independent effort to identify any such rights. Information 340 on the procedures with respect to rights in RFC documents can be 341 found in BCP 78 and BCP 79. 343 Copies of IPR disclosures made to the IETF Secretariat and any 344 assurances of licenses to be made available, or the result of an 345 attempt made to obtain a general license or permission for the use of 346 such proprietary rights by implementers or users of this 347 specification can be obtained from the IETF on-line IPR repository at 348 http://www.ietf.org/ipr. 350 The IETF invites any interested party to bring to its attention any 351 copyrights, patents or patent applications, or other proprietary 352 rights that may cover technology that may be required to implement 353 this standard. Please address the information to the IETF at 354 ietf-ipr@ietf.org. 356 Acknowledgment 358 Funding for the RFC Editor function is provided by the IETF 359 Administrative Support Activity (IASA).