idnits 2.17.1 draft-ietf-dnsext-ds-sha256-01.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 274. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 251. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 264. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 75: '...sults of the digest algorithm MUST NOT...' RFC 2119 keyword, line 143: '... Implementations MUST support the use ...' RFC 2119 keyword, line 146: '... implementations MUST be able to prefe...' RFC 2119 keyword, line 148: '... behavior SHOULD by the default. Va...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (November 29, 2005) is 6716 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA256' Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Hardaker 3 Internet-Draft Sparta 4 Expires: June 2, 2006 November 29, 2005 6 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) 7 draft-ietf-dnsext-ds-sha256-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on June 2, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document specifies how to use the SHA-256 digest type in DNS 41 Delegation Signer (DS) Resource Records (RRs). DS records, when 42 stored in a parent zone, point to key signing DNSKEY key(s) in a 43 child zone. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Implementing the SHA-256 algorithm for DS record support . . . 3 49 2.1. DS record field values . . . . . . . . . . . . . . . . . . 3 50 2.2. DS Record with SHA-256 Wire Format . . . . . . . . . . . . 3 51 2.3. Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4 52 3. Implementation Requirements . . . . . . . . . . . . . . . . . . 4 53 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 5 54 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 56 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 57 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 59 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 Intellectual Property and Copyright Statements . . . . . . . . . . 8 63 1. Introduction 65 The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent 66 zones to distribute a cryptographic digest of a child's Key Signing 67 Key (KSK) DNSKEY RR. This DS RR is signed using the parent zone's 68 private half of it's DNSKEY and the signature is published in a RRSIG 69 record. 71 2. Implementing the SHA-256 algorithm for DS record support 73 This document specifies that the digest type code [XXX: To be 74 assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256] for 75 use within DS records. The results of the digest algorithm MUST NOT 76 be truncated and the entire 32 byte digest result is to be published 77 in the DS record. 79 2.1. DS record field values 81 Using the SHA-256 digest algorithm within a DS record will make use 82 of the following DS-record fields: 84 Digest type: [XXX: To be assigned by IANA; likely 2] 86 Digest: A SHA-256 bit digest value calculated by using the following 87 formula ("|" denotes concatenation). The resulting value is not 88 truncated and the entire 32 byte result is to used in the 89 resulting DS record and related calculations. 91 digest = SHA_256(DNSKEY owner name | DNSKEY RDATA) 93 where DNSKEY RDATA is defined by [RFC4034] as: 95 DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key 97 The Key Tag field and Algorithm fields remain unchanged by this 98 document and are specified in the [RFC4034] specification. 100 2.2. DS Record with SHA-256 Wire Format 102 The resulting packet format for the resulting DS record will be [XXX: 103 IANA assignment should replace the 2 below]: 105 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 106 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Key Tag | Algorithm | DigestType=2 | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 / / 111 / Digest (length for SHA-256 is 32 bytes) / 112 / / 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 115 2.3. Example DS Record Using SHA-256 117 The following is an example DSKEY and matching DS record. This 118 DNSKEY record comes from the example DNSKEY/DS records found in 119 section 5.4 of [RFC4034]. 121 The DNSKEY record:: 123 dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz 124 fwJr1AYtsmx3TGkJaNXVbfi/ 125 2pHm822aJ5iI9BMzNXxeYCmZ 126 DRD99WYwYqUSdjMmmAphXdvx 127 egXd/M5+X7OrzKBaMbCVdFLU 128 Uh6DhweJBjEVv5f2wwjM9Xzc 129 nOf+EPbtG9DMBmADjFDc2w/r 130 ljwvFw== 131 ) ; key id = 60485 133 The resulting DS record covering the above DNSKEY record using a SHA- 134 256 digest: [RFC Editor: please replace XXX with the assigned digest 135 type (likely 2):] 137 dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C 138 CEB1E3E0614B93C4F9E99B83 139 83F6A1E4469DA50A ) 141 3. Implementation Requirements 143 Implementations MUST support the use of the SHA-256 algorithm in DS 144 RRs. 146 Validator implementations MUST be able to prefer DS records 147 containing SHA-256 digests over those containing SHA-1 digests. This 148 behavior SHOULD by the default. Validator implementations MAY 149 provide configuration settings that allow network operators to 150 specify preference policy when validating multiple DS records 151 containing different digest types. 153 4. Deployment Considerations 155 If a validator does not support the SHA-256 digest type and no other 156 DS RR exists in a zone's DS RRset with a supported digest type, then 157 the validator has no supported authentication path leading from the 158 parent to the child. The resolver should treat this case as it would 159 the case of an authenticated NSEC RRset proving that no DS RRset 160 exists, as described in [RFC4035], section 5.2. 162 Because zone administrators can not control the deployment support of 163 SHA-256 in deployed validators that may referencing any given zone, 164 deployments should consider publishing both SHA-1 and SHA-256 based 165 DS records for a while. Whether to publish both digest types 166 together and for how long is a policy decision that extends beyond 167 the scope of this document. 169 5. IANA Considerations 171 The Digest Type to be used for supporting SHA-256 within DS records 172 needs to be assigned by IANA. This document requests that the Digest 173 Type value of 2 be assigned to the SHA-256 digest algorithm. 175 At the time of this writing, the current digest types assigned for 176 use in DS records are as follows: 178 VALUE Digest Type Status 179 0 Reserved - 180 1 SHA-1 MANDATORY 181 2 SHA-256 MANDATORY 182 3-255 Unassigned - 184 6. Security Considerations 186 Because of the weaknesses recently discovered within the SHA-1 187 algorithm, users of DNSSEC are encouraged to deploy the use of SHA- 188 256 as soon as the software implementations in use allow for it. 190 At the time of this publication, the SHA-256 digest algorithm is 191 considered sufficiently strong for the immediate future. It is also 192 considered sufficient for use in DNSSEC DS RRs for the immediate 193 future. However, future published attacks may, of course, weaken the 194 usability of this algorithm within the DS RRs. It is beyond the 195 scope of this document to speculate extensively on the cryptographic 196 strength of the SHA-256 digest algorithm. 198 Likewise, it is also beyond the scope of this document to specify 199 whether or for how long SHA-1 based DS records should be 200 simultaneously published alongside SHA-256 based DS records. 202 7. Acknowledgments 204 This document is a minor extension to the existing DNSSEC documents 205 and those authors are gratefully appreciated for the hard work that 206 went into the base documents. 208 The following people contributed to valuable technical content of 209 this document: Roy Arends, Olafur Gudmundsson, Olaf M. Kolkman, Scott 210 Rose, Sam Weiler. 212 8. References 214 8.1. Normative References 216 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 217 Rose, "DNS Security Introduction and Requirements", 218 RFC 4033, March 2005. 220 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 221 Rose, "Resource Records for the DNS Security Extensions", 222 RFC 4034, March 2005. 224 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 225 Rose, "Protocol Modifications for the DNS Security 226 Extensions", RFC 4035, March 2005. 228 [SHA256] National Institute of Standards and Technology, "Secure 229 Hash Algorithm. NIST FIPS 180-2", August 2002. 231 8.2. Informative References 232 Author's Address 234 Wes Hardaker 235 Sparta 236 P.O. Box 382 237 Davis 95617 238 US 240 Email: hardaker@tislabs.com 242 Intellectual Property Statement 244 The IETF takes no position regarding the validity or scope of any 245 Intellectual Property Rights or other rights that might be claimed to 246 pertain to the implementation or use of the technology described in 247 this document or the extent to which any license under such rights 248 might or might not be available; nor does it represent that it has 249 made any independent effort to identify any such rights. Information 250 on the procedures with respect to rights in RFC documents can be 251 found in BCP 78 and BCP 79. 253 Copies of IPR disclosures made to the IETF Secretariat and any 254 assurances of licenses to be made available, or the result of an 255 attempt made to obtain a general license or permission for the use of 256 such proprietary rights by implementers or users of this 257 specification can be obtained from the IETF on-line IPR repository at 258 http://www.ietf.org/ipr. 260 The IETF invites any interested party to bring to its attention any 261 copyrights, patents or patent applications, or other proprietary 262 rights that may cover technology that may be required to implement 263 this standard. Please address the information to the IETF at 264 ietf-ipr@ietf.org. 266 Disclaimer of Validity 268 This document and the information contained herein are provided on an 269 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 270 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 271 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 272 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 273 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 274 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 276 Copyright Statement 278 Copyright (C) The Internet Society (2005). This document is subject 279 to the rights, licenses and restrictions contained in BCP 78, and 280 except as set forth therein, the authors retain all their rights. 282 Acknowledgment 284 Funding for the RFC Editor function is currently provided by the 285 Internet Society.