idnits 2.17.1 draft-turner-md2-to-historic-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 draft header indicates that this document obsoletes RFC1319, but the abstract doesn't seem to directly say this. It does mention RFC1319 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 29, 2010) is 4868 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1319 (ref. 'MD2') (Obsoleted by RFC 6149) -- Obsolete informational reference (is this intentional?): RFC 1320 (ref. 'MD4') (Obsoleted by RFC 6150) -- Obsolete informational reference (is this intentional?): RFC 2313 (Obsoleted by RFC 2437) -- Obsolete informational reference (is this intentional?): RFC 2437 (Obsoleted by RFC 3447) -- Obsolete informational reference (is this intentional?): RFC 2630 (Obsoleted by RFC 3369, RFC 3370) -- Obsolete informational reference (is this intentional?): RFC 2898 (Obsoleted by RFC 8018) -- Obsolete informational reference (is this intentional?): RFC 3369 (Obsoleted by RFC 3852) -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 4572 (Obsoleted by RFC 8122) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Turner 3 Internet-Draft IECA 4 Obsoletes: 1319 (once approved) L. Chen 5 Intended Status: Informational NIST 6 Expires: June 28, 2011 December 29, 2010 8 MD2 to Historic Status 9 draft-turner-md2-to-historic-10.txt 11 Abstract 13 This document recommends the retirement of MD2 and discusses the 14 reasons for doing so. This document recommends RFC 1319 be moved to 15 Historic status. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 28, 2011. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Internet-Draft MD2 to Historic 2010-12-29 51 1. Introduction 53 MD2 [MD2] is a message digest algorithm that takes as input a message 54 of arbitrary length and produces as output a 128-bit "fingerprint" or 55 "message digest" of the input. This document recommends that MD2 be 56 retired. Specifically, this document recommends RFC 1319 [MD2] be 57 moved to Historic status. The reasons for taking this action are 58 discussed. 60 [HASH-Attack] summarizes the use of hashes in many protocols and 61 discusses how attacks against a message digest algorithm's one-way 62 and collision-free properties affect and do not affect Internet 63 protocols. Familiarity with [HASH-Attack] is assumed. 65 2. Rationale 67 MD2 was published in 1992 as an Informational RFC. Since its 68 publication, MD2 has been shown to not be collision-free [ROCH1995] 69 [KNMA2005] [ROCH1997], albeit successful collision attacks for 70 properly implemented MD2 are not that damaging. MD2 has also been 71 shown to have successful pre-image and second-preimage attacks 72 [KNMA2005] [MULL2004] [KMM2010]. 74 3. Documents that Reference RFC 1319 76 Use of MD2 has been specified in the following RFCs: 78 Proposed Standard (PS): 80 o [RFC3279] Algorithms and Identifiers for the Internet X.509 Public 81 Key Infrastructure Certificate and Certificate Revocation 82 List (CRL) Profile. 84 o [RFC4572] Connection-Oriented Media Transport over the Transport 85 Layer Security (TLS) Protocol in the Session Description 86 Protocol (SDP). 88 Informational: 90 o [RFC1983] Internet Users' Glossary. 92 o [RFC2315] PKCS #7: Cryptographic Message Syntax Version 1.5. 94 o [RFC2898] PKCS #5: Password-Based Cryptography Specification 95 Version 2.0. 97 o [RFC3447] Public-Key Cryptography Standards (PKCS) #1: RSA 98 Cryptography Specifications Version 2.1. 100 Internet-Draft MD2 to Historic 2010-12-29 102 Experimental: 104 o [RFC2660] The Secure HyperText Transfer Protocol. 106 There are other RFCs that refer to MD2, but their status is either 107 Historic or Obsoleted. References and discussions about these RFCs 108 are omitted. The exceptions are: 110 o [RFC2313] PKCS #1: RSA Encryption Version 1.5. 112 o [RFC2437] PKCS #1: RSA Cryptography Specifications Version 2.0. 114 4. Impact on Moving MD2 to Historic 116 The impact of moving MD2 to Historic on the RFCs specified in Section 117 3 is minimal, as described below. 119 Regarding PS RFCs: 121 o MD2 support in TLS was dropped in TLS 1.1. 123 o MD2 support is optional in [RFC4572], and SHA-1 is specified as the 124 preferred algorithm. 126 o MD2 is included in the original PKIX certificate profile and the 127 PKIX algorithm document [RFC3279] for compatibility with older 128 applications, but its use is discouraged. SHA-1 is identified as 129 the preferred algorithm for the Internet PKI. 131 Regarding Informational RFCs: 133 o The Internet Users' Guide [RFC1983] provided a definition for 134 Message Digest and listed MD2 as one example. 136 o PKCS#1 v1.5 [RFC2313] stated that there are no known attacks 137 against MD2. PKCS#1 v2.0 [RFC2437] updated this stance to indicate 138 that MD2 should only be supported for backward compatibility and to 139 mention the attacks in [ROCH1995]. PKCS#1 [RFC3447] indicates that 140 support MD2 is only retained for compatibility with existing 141 applications. 143 o PKCS#5 [RFC2898] recommends that the Password Based Encryption 144 Scheme (PBES) that uses MD2 not be used for new applications. 146 Internet-Draft MD2 to Historic 2010-12-29 148 o PKCS#7 [RFC2315] was replaced by a series of standards track 149 publications, "Cryptographic Message Syntax" [RFC2630] [RFC3369] 150 [RFC5652] and "Cryptographic Message Syntax (CMS) Algorithms" 151 [RFC3370]. Support for MD2 was dropped in [RFC3370]. 153 RFC 2818 "HTTP Over TLS", which does not reference MD2, largely 154 supplanted implementation of [RFC2660]. [RFC2660] specified MD2 for 155 use both as a digest algorithm as a MAC algorithm [RFC2104]. Note 156 that this is the only reference to HMAC-MD2 found in the RFC 157 repository. 159 5. Other Considerations 161 MD2 has also fallen out of favor because it is slower than both MD4 162 [MD4] and MD5 [MD5]. This is because MD2 was optimized for 8-bit 163 machines while MD4 and MD5 were optimized for 32-bit machines. MD2 164 is also slower than the Secure Hash Standard (SHS) [SHS] algorithms: 165 SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. 167 6. Security Considerations 169 MD2 is different from MD4 and MD5 in that is not a straight Merkle- 170 Damgaard design. For a padded message with t blocks, it generates a 171 nonlinear checksum as its t+1 block. The checksum is considered as 172 the final block input of MD2. 174 As confirmed in 1997 by Rogier et. al. [ROCH1997], the collision 175 resistance property of MD2 highly depends on the nonlinear checksum. 176 Without the checksum, a collision can be found in 2^12 MD2 operations 177 according, while with the checksum, the best collision attack takes 178 2^63.3 operations with 2^50 memory complexity [MULL2004], which is 179 not significantly better than the birthday attack. 181 Even though collision attacks on MD2 are not significantly more 182 powerful than the birthday attack, MD2 was found not to be one-way. 183 In [KMM2010], a pre-image can be found with 2^104 MD2 operations. In 184 an improved attack described in [KMM2010], a pre-image can be found 185 in 2^73 MD2 operations. Because of this "invertible" property of 186 MD2, when using MD2 in HMAC, it may leak information of the keys. 188 Obviously, the pre-image attack can be used to find a second pre- 189 image. The second pre-image attack is even more severe than a 190 collision attack to digital signatures. Therefore, MD2 must not be 191 used for digital signatures. 193 Some may find the guidance for key lengths and algorithm strengths in 194 [SP800-57] and [SP800-131] useful. 196 Internet-Draft MD2 to Historic 2010-12-29 198 7. Recommendation 200 Despite MD2 seeing some deployment on the Internet, this 201 specification recommends obsoleting MD2. MD2 is not a reasonable 202 candidate for further standardization and should be deprecated in 203 favor of one or more existing hash algorithms (e.g., SHA-256 [SHS]). 205 RSA Security considers it appropriate to move the MD2 algorithm to 206 Historic status. It takes a number of years to deploy crypto and it 207 also takes a number of years to withdraw it. Algorithms need to be 208 withdrawn before a catastrophic break is discovered. MD2 is clearly 209 showing signs of weakness and implementations should strongly 210 consider removing support and migrating to another hash algorithm. 212 8. IANA Considerations 214 None. 216 9. Acknowledgements 218 We'd like to thank RSA for publishing MD2. We'd also like to thank 219 all the cryptographers who studied the algorithm. For his 220 contribution to this draft we'd like to thank Ran Atkinson, Alfred 221 Hoenes, John Linn, and Martin Rex. 223 10. Informative References 225 [HASH-Attack] Hoffman, P., and B. Schneier, "Attacks on Cryptographic 226 Hashes in Internet Protocols", RFC 4270, November 2005. 228 [KNMA2005] Knudsen, L., and J. Mathiassen, "Preimage and Collision 229 Attacks on MD2," FSE 2005. 231 [KMM2010] Knudsen, L., Mathiassen, J., Muller, F., and Thomsen, S., 232 "Cryptanalysis of MD2", Journal of Cryptology, 23(1):72-90, 233 2010. 235 [MD2] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, 236 April 1992. 238 [MULL2004] Muller, F., "The MD2 Hash Function Is Not One-Way", 239 ASIACRYPT, LNCS 3329, pp. 214-229, Springer, 2004. 241 [MD4] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, April 242 1992. 244 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 245 1992. 247 Internet-Draft MD2 to Historic 2010-12-29 249 [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, August 250 1996. 252 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 253 Hashing for Message Authentication", RFC 2104, February 254 1997. 256 [RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 257 2313, March 1998. 259 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 260 1.5," RFC 2315, March 1998. 262 [RFC2437] Kaliski, B., and J. Staddon, "PKCS #1: RSA Cryptography 263 Specifications Version 2.0", RFC 2437, October 1998. 265 [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 266 1999. 268 [RFC2660] Rescorla, E., and A. Schiffman, "The Secure HyperText 269 Transfer Protocol", RFC 2660, August 1999. 271 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 272 Specification Version 2.0", RFC 2898, September 2000. 274 [RFC3279] Polk, W., Housley, R., and L. Bassham, "Algorithms and 275 Identifiers for the Internet X.509 Public Key 276 Infrastructure Certificate and Certificate Revocation List 277 (CRL) Profile", RFC 3279, April 2002. 279 [RFC3369] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 280 3369, August 2002. 282 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 283 Algorithms", RFC 3370, August 2002. 285 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 286 Standards (PKCS) #1: RSA Cryptography Specifications 287 Version 2.1" RFC 3447, February 2003. 289 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 290 Transport Layer Security (TLS) Protocol in the Session 291 Description Protocol (SDP)", RFC 4572, July 2006. 293 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 294 RFC 5652, August 2002. 296 [ROCH1995] Rogier, N., and P. Chauvaud, "The compression function of 298 Internet-Draft MD2 to Historic 2010-12-29 300 MD2 is not collision free", Presented at Selected Areas in 301 Cryptography '95, Carleton University, Ottawa, Canada. May 302 18-19, 1995. 304 [ROCH1997] Rogier, N. and P. Chauvaud, "MD2 is not secure without the 305 checksum byte", Des. Codes Cryptogr. 12(3), 245-251 306 (1997). 308 [SP800-57] National Institute of Standards and Technology (NIST), 309 Special Publication 800-57: Recommendation for Key 310 Management - Part 1 (Revised), March 2007. 312 [SP800-131] National Institute of Standards and Technology (NIST), 313 Special Publication 800-131: DRAFT Recommendation for the 314 Transitioning of Cryptographic Algorithms and Key Sizes, 315 June 2010. 317 [SHS] National Institute of Standards and Technology (NIST), FIPS 318 Publication 180-3: Secure Hash Standard, October 2008. 320 Authors' Addresses 322 Sean Turner 323 IECA, Inc. 324 3057 Nutley Street, Suite 106 325 Fairfax, VA 22031 326 USA 328 EMail: turners@ieca.com 330 Lily Chen 331 National Institute of Standards and Technology 332 100 Bureau Drive, Mail Stop 8930 333 Gaithersburg, MD 20899-8930 334 USA 336 EMail: lily.chen@nist.gov