idnits 2.17.1 draft-dupont-dnsext-tsig-md5-deprecated-00.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 190. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 201. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 208. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 214. 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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (May 11, 2008) is 5828 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) ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 4635 (Obsoleted by RFC 8945) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 4634 (Obsoleted by RFC 6234) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Dupont 3 Internet-Draft ISC 4 Intended status: Standards Track May 11, 2008 5 Expires: November 12, 2008 7 Deprecated HMAC MD5 in TSIG 8 draft-dupont-dnsext-tsig-md5-deprecated-00.txt 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 November 12, 2008. 35 Abstract 37 The goal of this document is to deprecate the usage of HMAC MD5 as an 38 algorithm for the TSIG (secret key transaction authentication) 39 resource record in the DNS (domain name system). 41 1. Introduction 43 The secret key transaction authentication for DNS (TSIG, [RFC2845]) 44 was defined with the HMAC MD5 [RFC2104] cryptographic algorithm. As 45 the MD5 security is today recognized to be lower than expected, the 46 [RFC4635] standardized new TSIG algorithms based on SHA 47 [RFC3174][RFC3874] [RFC4634] digests. 49 But it failed to deprecate the HMAC MD5 algorithm. This document is 50 targeted to correct this point, in details: 51 1. Mark HMAC-MD5.SIG-ALG.REG.INT as deprecated and replaced by hmac- 52 sha256 in the TSIG algorithm name registry managed by the IANA 53 under the IETF Consensus Policy [RFC2434] 54 2. Make HMAC-MD5.SIG-ALG.REG.INT support Optional for 55 implementations 56 3. Provide a keying material derivation for the secret key 57 establishment for DNS (TKEY, [RFC2930]) using a Diffie-Hellman 58 exchange 59 4. Finally recommend the use of at least hmac-sha256. 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC2119]. 65 2. IANA Considerations 67 In the registry of TSIG algorithm names, add this comment 68 "(deprecated, see hmac-sha256)" in the HMAC-MD5.SIG-ALG.REG.INT 69 entry. 71 This is copied from the registry of DNSSEC algorithm numbers which 72 was updated by [RFC3110]. 74 3. Implementation Requirements 76 The table of section 3 of [RFC4635] is updated into: 78 +-------------------+--------------------------+ 79 | Requirement Level | Algorithm Name | 80 +-------------------+--------------------------+ 81 | Optional | HMAC-MD5.SIG-ALG.REG.INT | 82 | Optional | gss-tsig | 83 | Mandatory | hmac-sha1 | 84 | Optional | hmac-sha224 | 85 | Mandatory | hmac-sha256 | 86 | Optional | hmac-sha384 | 87 | Optional | hmac-sha512 | 88 +-------------------+--------------------------+ 90 Implementations that support TSIG MUST also implement HMAC SHA1 and 91 HMAC SHA256 and MAY implement gss-tsig and the other algorithms 92 listed above. 94 4. TKEY keying material derivation 96 When the TKEY [RFC2930] uses a Diffie-Hellman exchange, the keying 97 material is derived from the shared secret and TKEY resource record 98 data using MD5 [RFC1321] at the end of section 4.1 page 8. 100 This is amended into: 102 keying material = 103 XOR ( DH value, SHA256 ( query data | DH value ) | 104 SHA256 ( server data | DH value ) ) 106 using the same conventions. 108 5. Security Considerations 110 The use of MD5 and HMAC MD5 is NOT RECOMMENDED in TSIG and related 111 specifications (i.e., TKEY). 113 But SHA-1 seems to be vulnerable too, so the use of at least SHA256 114 is RECOMMENDED. As implementations which support TSIG are REQUIRED 115 to implement HMAC SHA256, in particular the hmac-sha256 algorithm is 116 RECOMMENDED for default use in TSIG. 118 6. Acknowledgments 120 Cryptographic module validation programs made MD5 not approved so not 121 available. They provide a good incentive to deprecate MD5 at a place 122 it is still mandatory to support and likely heavily used. 124 Olafur Gudmundsson kindly helped in the procedure to deprecate the 125 MD5 usage in TSIG, i.e., the procedure which gave this memo. 127 7. References 129 7.1. Normative References 131 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 132 Requirement Levels", RFC 2119, BCP 14, March 1997. 134 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 135 Wellington, "Secret Key Transaction Authentication for DNS 136 (TSIG)", RFC 2845, May 2000. 138 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY 139 RR)", RFC 2930, September 2000. 141 [RFC4635] Eastlake, D., "HMAC SHA TSIG Algorithm Identifiers", 142 RFC 4635, August 2006. 144 7.2. Informative References 146 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 147 April 1992. 149 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 150 Hashing for Message Authentication", RFC 2104, 151 February 1997. 153 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 154 IANA Considerations Section in RFCs", RFC 2434, BCP 26, 155 October 1998. 157 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 158 Name System (DNS)", RFC 3110, May 2001. 160 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 161 (SHA1)", RFC 3174, September 2001. 163 [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", 164 RFC 3874, September 2004. 166 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 167 (SHA and HMAC-SHA)", RFC 4634, July 2006. 169 Author's Address 171 Francis Dupont 172 ISC 174 Email: Francis.Dupont@fdupont.fr 176 Full Copyright Statement 178 Copyright (C) The IETF Trust (2008). 180 This document is subject to the rights, licenses and restrictions 181 contained in BCP 78, and except as set forth therein, the authors 182 retain all their rights. 184 This document and the information contained herein are provided on an 185 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 186 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 187 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 188 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 189 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 190 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 192 Intellectual Property 194 The IETF takes no position regarding the validity or scope of any 195 Intellectual Property Rights or other rights that might be claimed to 196 pertain to the implementation or use of the technology described in 197 this document or the extent to which any license under such rights 198 might or might not be available; nor does it represent that it has 199 made any independent effort to identify any such rights. Information 200 on the procedures with respect to rights in RFC documents can be 201 found in BCP 78 and BCP 79. 203 Copies of IPR disclosures made to the IETF Secretariat and any 204 assurances of licenses to be made available, or the result of an 205 attempt made to obtain a general license or permission for the use of 206 such proprietary rights by implementers or users of this 207 specification can be obtained from the IETF on-line IPR repository at 208 http://www.ietf.org/ipr. 210 The IETF invites any interested party to bring to its attention any 211 copyrights, patents or patent applications, or other proprietary 212 rights that may cover technology that may be required to implement 213 this standard. Please address the information to the IETF at 214 ietf-ipr@ietf.org.