idnits 2.17.1 draft-ietf-dnsext-dnssec-rsasha256-02.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 282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 306. 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 127: '... The FF octet MUST be repeated the m...' RFC 2119 keyword, line 159: '... implementations SHOULD be able to sup...' RFC 2119 keyword, line 164: '... SHOULD ignore the SHA-1 signature. ...' RFC 2119 keyword, line 166: '... SHOULD mark the data with the secur...' RFC 2119 keyword, line 180: '... [TBA] RSA/SHA-256 [RSASHA256] y [TBA] OPTIONAL...' (4 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 (December 11, 2007) is 5980 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: 'TBA' on line 183 -- Looks like a reference, but probably isn't: 'Mnemonic' on line 178 -- Looks like a reference, but probably isn't: 'RSASHA256' on line 180 -- Looks like a reference, but probably isn't: 'RSASHA256NSEC3' on line 181 -- Looks like a reference, but probably isn't: 'RSASHA512' on line 182 -- Looks like a reference, but probably isn't: 'RSASHA512NSEC3' on line 183 ** Obsolete normative reference: RFC 3447 (ref. '4') (Obsoleted by RFC 8017) -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 14 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: June 13, 2008 December 11, 2007 6 Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records 7 for DNSSEC 8 draft-ietf-dnsext-dnssec-rsasha256-02 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 June 13, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 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, RFC4033, RFC4034, and RFC4035). 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. Implementation Considerations . . . . . . . . . . . . . . . . . 5 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 57 6.1. SHA-1 versus SHA-2 Considerations for RRSIG resource 58 records . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 6.2. Signature Type Downgrade Attacks . . . . . . . . . . . . . 6 60 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 63 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 Intellectual Property and Copyright Statements . . . . . . . . . . 8 67 1. Introduction 69 The Domain Name System (DNS) is the global hierarchical distributed 70 database for Internet Addressing. The DNS has been extended to use 71 cryptographic keys and digital signatures for the verification of the 72 integrity of its data. RFC4033 [1], RFC4034 [2], and RFC4035 [3] 73 describe these DNS Security Extensions, called DNSSEC. 75 RFC4034 describes how to store DNSKEY and RRSIG resource records, and 76 specifies a list of cryptographic algorithms to use. This document 77 extends that list with the algorithm RSA/SHA-256 and RSA/SHA-512, and 78 specifies how to store DNSKEY data and how to produce RRSIG resource 79 records with these hash algorithms. 81 Familiarity with DNSSEC, RSA [7] and the SHA-2 [5] family of 82 algorithms is assumed in this document. 84 To refer to both SHA-256 and SHA-512, this document will use the name 85 SHA-2. This is done to improve readability. When a part of text is 86 specific for either SHA-256 or SHA-512, their specific names are 87 used. The same goes for RSA/SHA-256 and RSA/SHA-512, which will be 88 grouped using the name RSA/SHA-2. 90 2. DNSKEY Resource Records 92 The format of the DNSKEY RR can be found in RFC4034 [2] and RFC3110 93 [6]. 95 2.1. RSA/SHA-256 DNSKEY Resource Records 97 RSA public keys for use with RSA/SHA-256 are stored in DNSKEY 98 resource records (RRs) with the algorithm number [TBA]. 100 For use with NSEC3, the algorithm number of RSA/SHA-256 will be 101 [TBA]. 103 2.2. RSA/SHA-512 DNSKEY Resource Records 105 RSA public keys for use with RSA/SHA-512 are stored in DNSKEY 106 resource records (RRs) with the algorithm number [TBA]. 108 For use with NSEC3, the algorithm number of RSA/SHA-512 will be 109 [TBA]. 111 3. RRSIG Resource Records 113 The value of the signature field in the RRSIG RR is calculated as 114 follows. The values for the fields that precede the signature data 115 are specified in RFC4034 [2]. 117 hash = SHA-XXX(data) 119 Where XXX is either 256 or 512, depending on the algorithm used. 121 signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) 123 Where SHA-XXX is the message digest algorithm as specified in FIPS 124 180 [5], | is concatenation, 00, 01, FF and 00 are fixed octets of 125 corresponding hexadecimal value, "e" is the private exponent of the 126 signing RSA key, and "n" is the public modulus of the signing key. 127 The FF octet MUST be repeated the maximum number of times so that the 128 total length of the signature equals the length of the modulus of the 129 signer's public key ("n"). "data" is the data of the resource record 130 set that is signed, as specified in RFC4034 [2]. 132 The prefix should make the use of standard cryptographic libraries 133 easier. These specifications are taken directly from PKCS #1 v2.1 134 section 9.2 [4]. The prefixes for the different algorithms are 135 specified below. 137 3.1. RSA/SHA-256 RRSIG Resource Records 139 RSA/SHA-256 signatures are stored in the DNS using RRSIG resource 140 records (RRs) with algorithm number [TBA]. 142 The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as 143 specified in PKCS 2.1 [4]: 145 hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 147 3.2. RSA/SHA-512 RRSIG Resource Records 149 RSA/SHA-512 signatures are stored in the DNS using RRSIG resource 150 records (RRs) with algorithm number [TBA]. 152 The prefix is the ASN.1 BER SHA-512 algorithm designator prefix as 153 specified in PKCS 2.1 [4]: 155 hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40 157 4. Implementation Considerations 159 DNSSEC aware implementations SHOULD be able to support RRSIG resource 160 records with the RSA/SHA-2 algorithms. 162 If both RSA/SHA-2 and RSA/SHA-1 RRSIG resource records are available 163 for a certain rrset, with a secure path to their keys, the validator 164 SHOULD ignore the SHA-1 signature. If the RSA/SHA-2 signature does 165 not verify the data, and the RSA/SHA-1 signature does, the validator 166 SHOULD mark the data with the security status from the RSA/SHA-2 167 signature. 169 5. IANA Considerations 171 IANA has not yet assigned an algorithm number for RSA/SHA-256 and 172 RSA/SHA-512. 174 The algorithm list from RFC4034 Appendix A.1 [2] is extended with the 175 following entries: 177 Zone 178 Value Algorithm [Mnemonic] Signing References Status 179 ----- ----------- ----------- ------- ---------- -------- 180 [TBA] RSA/SHA-256 [RSASHA256] y [TBA] OPTIONAL 181 [TBA] RSA/SHA-256-NSEC3 [RSASHA256NSEC3] y [TBA] OPTIONAL 182 [TBA] RSA/SHA-512 [RSASHA512] y [TBA] OPTIONAL 183 [TBA] RSA/SHA-512-NSEC3 [RSASHA512NSEC3] y [TBA] OPTIONAL 185 6. Security Considerations 187 6.1. SHA-1 versus SHA-2 Considerations for RRSIG resource records 189 Users of DNSSEC are encouraged to deploy SHA-2 as soon as software 190 implementations allow for it. SHA-2 is widely believed to be more 191 resilient to attack than SHA-1, and confidence in SHA-1's strength is 192 being eroded by recently-announced attacks. Regardless of whether or 193 not the attacks on SHA-1 will affect DNSSEC, it is believed (at the 194 time of this writing) that SHA-2 is the better choice for use in 195 DNSSEC records. 197 SHA-2 is considered sufficiently strong for the immediate future, but 198 predictions about future development in cryptography and 199 cryptanalysis are beyond the scope of this document. 201 6.2. Signature Type Downgrade Attacks 203 Since each RRset MUST be signed with each algorithm present in the 204 DNSKEY RRset at the zone apex (see [3] Section 2.2), a malicious 205 party cannot filter out the RSA/SHA-2 RRSIG, and force the validator 206 to use the RSA/SHA-1 signature if both are present in the zone. 207 Together with the implementation considerations from Section 4 of 208 this document, this provides resilience against algorithm downgrade 209 attacks, if the validator supports RSA/SHA-2. 211 7. Acknowledgments 213 This document is a minor extension to RFC4034 [2]. Also, we try to 214 follow the documents RFC3110 [6] and RFC4509 [8] for consistency. 215 The authors of and contributors to these documents are gratefully 216 acknowledged for their hard work. 218 The following people provided additional feedback and text: Jaap 219 Akkerhuis, Rob Austein, Miek Gieben, Scott Rose and Wouter 220 Wijngaards. 222 8. References 224 8.1. Normative References 226 [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 227 "DNS Security Introduction and Requirements", RFC 4033, 228 March 2005. 230 [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 231 "Resource Records for the DNS Security Extensions", RFC 4034, 232 March 2005. 234 [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 235 "Protocol Modifications for the DNS Security Extensions", 236 RFC 4035, March 2005. 238 [4] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards 239 (PKCS) #1: RSA Cryptography Specifications Version 2.1", 240 RFC 3447, February 2003. 242 [5] National Institute of Standards and Technology, "Secure Hash 243 Standard", FIPS PUB 180-2, August 2002. 245 [6] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 246 System (DNS)", RFC 3110, May 2001. 248 8.2. Informative References 250 [7] Schneier, B., "Applied Cryptography Second Edition: protocols, 251 algorithms, and source code in C", Wiley and Sons , ISBN 0-471- 252 11709-9, 1996. 254 [8] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) 255 Resource Records (RRs)", RFC 4509, May 2006. 257 Author's Address 259 Jelte Jansen 260 NLnet Labs 261 Kruislaan 419 262 Amsterdam 1098VA 263 NL 265 Email: jelte@NLnetLabs.nl 266 URI: http://www.nlnetlabs.nl/ 268 Full Copyright Statement 270 Copyright (C) The IETF Trust (2007). 272 This document is subject to the rights, licenses and restrictions 273 contained in BCP 78, and except as set forth therein, the authors 274 retain all their rights. 276 This document and the information contained herein are provided on an 277 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 278 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 279 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 280 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 281 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 282 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 284 Intellectual Property 286 The IETF takes no position regarding the validity or scope of any 287 Intellectual Property Rights or other rights that might be claimed to 288 pertain to the implementation or use of the technology described in 289 this document or the extent to which any license under such rights 290 might or might not be available; nor does it represent that it has 291 made any independent effort to identify any such rights. Information 292 on the procedures with respect to rights in RFC documents can be 293 found in BCP 78 and BCP 79. 295 Copies of IPR disclosures made to the IETF Secretariat and any 296 assurances of licenses to be made available, or the result of an 297 attempt made to obtain a general license or permission for the use of 298 such proprietary rights by implementers or users of this 299 specification can be obtained from the IETF on-line IPR repository at 300 http://www.ietf.org/ipr. 302 The IETF invites any interested party to bring to its attention any 303 copyrights, patents or patent applications, or other proprietary 304 rights that may cover technology that may be required to implement 305 this standard. Please address the information to the IETF at 306 ietf-ipr@ietf.org. 308 Acknowledgment 310 Funding for the RFC Editor function is provided by the IETF 311 Administrative Support Activity (IASA).