idnits 2.17.1 draft-ietf-dnsext-dnssec-rsasha256-05.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 323. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 347. 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 103: '...RSA/SHA-256 keys MUST NOT be less than...' RFC 2119 keyword, line 104: '... MUST NOT be more than 4096 bits....' RFC 2119 keyword, line 111: '...RSA/SHA-512 keys MUST NOT be less than...' RFC 2119 keyword, line 112: '... and MUST NOT be more than 4096 bits...' RFC 2119 keyword, line 131: '...ey. The FF octet MUST be repeated the...' (5 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 (July 29, 2008) is 5748 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 204, but not defined ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 4641 (Obsoleted by RFC 6781) Summary: 3 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 July 29, 2008 5 Expires: January 30, 2009 7 Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records 8 for DNSSEC 9 draft-ietf-dnsext-dnssec-rsasha256-05 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 January 30, 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 . . . . . . . . . . . . 4 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-1 and SHA-2 signatures . . . . . . . . . . 5 56 5.2. Support for NSEC3 denial of existence . . . . . . . . . . . 5 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 59 7.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource 60 Records . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 7.2. Signature Type Downgrade Attacks . . . . . . . . . . . . . 6 62 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 65 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 Intellectual Property and Copyright Statements . . . . . . . . . . 9 69 1. Introduction 71 The Domain Name System (DNS) is the global hierarchical distributed 72 database for Internet Addressing. The DNS has been extended to use 73 cryptographic keys and digital signatures for the verification of the 74 integrity of its data. RFC 4033 [RFC4033], RFC 4034 [RFC4034], and 75 RFC 4035 [RFC4035] describe these DNS Security Extensions, called 76 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 [SCHNEIER-1996] and the SHA-2 85 [FIPS.180-2.2002] family of 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 [RFC4034] and 96 RFC 3110 [RFC3110]. 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 The key size for RSA/SHA-256 keys MUST NOT be less than 512 bits, and 104 MUST NOT be more than 4096 bits. 106 2.2. RSA/SHA-512 DNSKEY Resource Records 108 RSA public keys for use with RSA/SHA-512 are stored in DNSKEY 109 resource records (RRs) with the algorithm number {TBA2}. 111 The key size for RSA/SHA-512 keys MUST NOT be less than 1024 bits, 112 and MUST NOT be more than 4096 bits. 114 3. RRSIG Resource Records 116 The value of the signature field in the RRSIG RR follow the RSASSA- 117 PKCS1-v1_5 signature scheme, and is calculated as follows. The 118 values for the RDATA fields that precede the signature data are 119 specified in RFC 4034 [RFC4034]. 121 hash = SHA-XXX(data) 123 Where XXX is either 256 or 512, depending on the algorithm used. 125 signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) 127 Where SHA-XXX is the message digest algorithm as specified in FIPS 128 PUB 180-2 [FIPS.180-2.2002], "|" is concatenation, "00", "01", "FF" 129 and "00" are fixed octets of corresponding hexadecimal value, "e" is 130 the private exponent of the signing RSA key, and "n" is the public 131 modulus of the signing key. The FF octet MUST be repeated the 132 maximum number of times so that the total length of the signature 133 equals the length of the modulus of the signer's public key ("n"). 134 "data" is the data of the resource record set that is signed, as 135 specified in RFC 4034 [RFC4034]. 137 The "prefix" is intended to make the use of standard cryptographic 138 libraries easier. These specifications are taken directly from the 139 specification of EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 section 9.2 140 [RFC3447]. The prefixes for the different algorithms are specified 141 below. 143 3.1. RSA/SHA-256 RRSIG Resource Records 145 RSA/SHA-256 signatures are stored in the DNS using RRSIG resource 146 records (RRs) with algorithm number {TBA1}. 148 The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as 149 specified in PKCS #1 v2.1 [RFC3447]: 151 hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 153 3.2. RSA/SHA-512 RRSIG Resource Records 155 RSA/SHA-512 signatures are stored in the DNS using RRSIG resource 156 records (RRs) with algorithm number {TBA2}. 158 The prefix is the ASN.1 BER SHA-512 algorithm designator prefix as 159 specified in PKCS #1 v2.1 [RFC3447]: 161 hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40 163 4. Deployment Considerations 165 4.1. Key Sizes 167 Apart from prohibiting RSA/SHA-512 signatures smaller than 1024 168 bytes, this document will not specify what size of keys to use. That 169 is an operational issue and depends largely on the environment and 170 intended use. Some good starting points for more information might 171 be DNSSEC Operational Practises [RFC4641], section 3.5, and NIST SP 172 800-57 [NIST800-57]. 174 4.2. Signature Sizes 176 In this family of signing algorithms, the size of signatures is 177 related to the size of the key, and not the hashing algorithm used in 178 the signing process. Therefore, RRSIG resource records produced with 179 RSA/SHA256 or RSA/SHA512 shall have the same size as those produced 180 with RSA/SHA1, if the keys have the same length. 182 5. Implementation Considerations 184 5.1. Support for SHA-1 and SHA-2 signatures 186 DNSSEC aware implementations SHOULD be able to support RRSIG resource 187 records with the RSA/SHA-2 algorithms. 189 5.2. Support for NSEC3 denial of existence 191 Implementations that have support for RSA/SHA-2 MUST also have 192 support for NSEC3 denial of existence, as specified in RFC 5155 193 [RFC5155]. 195 6. IANA Considerations 197 IANA has not yet assigned an algorithm number for RSA/SHA-256 and 198 RSA/SHA-512. 200 The algorithm list from RFC 4034 Appendix A.1 [RFC4034] is extended 201 with the following entries: 203 Zone 204 Value Algorithm [Mnemonic] Signing References Status 205 ----- ----------- ----------- ------- ----------- -------- 206 {TBA1} RSA/SHA-256 RSASHA256 y {this memo} OPTIONAL 207 {TBA2} RSA/SHA-512 RSASHA512 y {this memo} OPTIONAL 209 7. Security Considerations 211 7.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource Records 213 Users of DNSSEC are encouraged to deploy SHA-2 as soon as software 214 implementations allow for it. SHA-2 is widely believed to be more 215 resilient to attack than SHA-1, and confidence in SHA-1's strength is 216 being eroded by recently-announced attacks. Regardless of whether or 217 not the attacks on SHA-1 will affect DNSSEC, it is believed (at the 218 time of this writing) that SHA-2 is the better choice for use in 219 DNSSEC records. 221 SHA-2 is considered sufficiently strong for the immediate future, but 222 predictions about future development in cryptography and 223 cryptanalysis are beyond the scope of this document. 225 The signature scheme RSASSA-PKCS1-v1_5 is chosen to match the one 226 used for RSA/SHA-1 signatures. This should ease implementation of 227 the new hashing algorithms in DNSSEC software. 229 7.2. Signature Type Downgrade Attacks 231 Since each RRset MUST be signed with each algorithm present in the 232 DNSKEY RRset at the zone apex (see [RFC4035] Section 2.2), a 233 malicious party cannot filter out the RSA/SHA-2 RRSIG, and force the 234 validator to use the RSA/SHA-1 signature if both are present in the 235 zone. This should provide resilience against algorithm downgrade 236 attacks, if the validator supports RSA/SHA-2. 238 8. Acknowledgments 240 This document is a minor extension to RFC 4034 [RFC4034]. Also, we 241 try to follow the documents RFC 3110 [RFC3110] and RFC 4509 [RFC4509] 242 for consistency. The authors of and contributors to these documents 243 are gratefully acknowledged for their hard work. 245 The following people provided additional feedback and text: Jaap 246 Akkerhuis, Roy Arends, Rob Austein, Miek Gieben, Alfred Hoenes, 247 Michael St. Johns, Scott Rose and Wouter Wijngaards. 249 9. References 251 9.1. Normative References 253 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 254 Rose, "DNS Security Introduction and Requirements", 255 RFC 4033, March 2005. 257 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 258 Rose, "Resource Records for the DNS Security Extensions", 259 RFC 4034, March 2005. 261 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 262 Rose, "Protocol Modifications for the DNS Security 263 Extensions", RFC 4035, March 2005. 265 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 266 Standards (PKCS) #1: RSA Cryptography Specifications 267 Version 2.1", RFC 3447, February 2003. 269 [FIPS.180-2.2002] 270 National Institute of Standards and Technology, "Secure 271 Hash Standard", FIPS PUB 180-2, August 2002. 273 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 274 Name System (DNS)", RFC 3110, May 2001. 276 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 277 Security (DNSSEC) Hashed Authenticated Denial of 278 Existence", RFC 5155, March 2008. 280 9.2. Informative References 282 [SCHNEIER-1996] 283 Schneier, B., "Applied Cryptography Second Edition: 284 protocols, algorithms, and source code in C", Wiley and 285 Sons , ISBN 0-471-11709-9, 1996. 287 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 288 (DS) Resource Records (RRs)", RFC 4509, May 2006. 290 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 291 RFC 4641, September 2006. 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 Author's Address 300 Jelte Jansen 301 NLnet Labs 302 Kruislaan 419 303 Amsterdam 1098VA 304 NL 306 Email: jelte@NLnetLabs.nl 307 URI: http://www.nlnetlabs.nl/ 309 Full Copyright Statement 311 Copyright (C) The IETF Trust (2008). 313 This document is subject to the rights, licenses and restrictions 314 contained in BCP 78, and except as set forth therein, the authors 315 retain all their rights. 317 This document and the information contained herein are provided on an 318 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 319 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 320 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 321 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 322 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 323 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 325 Intellectual Property 327 The IETF takes no position regarding the validity or scope of any 328 Intellectual Property Rights or other rights that might be claimed to 329 pertain to the implementation or use of the technology described in 330 this document or the extent to which any license under such rights 331 might or might not be available; nor does it represent that it has 332 made any independent effort to identify any such rights. Information 333 on the procedures with respect to rights in RFC documents can be 334 found in BCP 78 and BCP 79. 336 Copies of IPR disclosures made to the IETF Secretariat and any 337 assurances of licenses to be made available, or the result of an 338 attempt made to obtain a general license or permission for the use of 339 such proprietary rights by implementers or users of this 340 specification can be obtained from the IETF on-line IPR repository at 341 http://www.ietf.org/ipr. 343 The IETF invites any interested party to bring to its attention any 344 copyrights, patents or patent applications, or other proprietary 345 rights that may cover technology that may be required to implement 346 this standard. Please address the information to the IETF at 347 ietf-ipr@ietf.org.