idnits 2.17.1 draft-simpson-des-as-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC-xxxx], [RFC-1829], [RFC-2420], [RFC-2419], [RFC-2405]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 1999) is 9082 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: 'DayDreamer' is mentioned on line 2, but not defined == Missing Reference: 'FIPS46-1' is mentioned on line 116, but not defined == Missing Reference: 'Chapter 7' is mentioned on line 125, but not defined == Missing Reference: 'RFC-1619' is mentioned on line 240, but not defined ** Obsolete undefined reference: RFC 1619 (Obsoleted by RFC 2615) == Unused Reference: 'Diffie81' is defined on line 276, but no explicit reference was found in the text == Unused Reference: 'FIPS-46-1' is defined on line 288, but no explicit reference was found in the text == Unused Reference: 'Hellman79' is defined on line 292, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BDRSSTW96' -- Possible downref: Non-RFC (?) normative reference: ref. 'CN94' -- Possible downref: Non-RFC (?) normative reference: ref. 'DH77' -- Possible downref: Non-RFC (?) normative reference: ref. 'Diffie81' -- Possible downref: Non-RFC (?) normative reference: ref. 'EFF98' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-46' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-46-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'Hellman79' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-xxxx' -- Possible downref: Non-RFC (?) normative reference: ref. 'SB88' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Weiner94' Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group W A Simpson 2 Internet Draft [DayDreamer] 3 S Bradner 4 [Harvard University] 5 expires in six months June 1999 7 Internet Security Algorithms Applicability Statement 8 draft-simpson-des-as-01.txt 10 Status of this Memo 12 This document is an Internet Draft, and is in full conformance with 13 all provisions of Section 10 of RFC2026, except that the right to 14 produce derivative works is not granted. 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 22 months, and may be updated, replaced, or obsoleted by other documents 23 at any time. It is not appropriate to use Internet Drafts as 24 reference 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 To view the list of Internet Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Distribution of this memo is unlimited. 34 Copyright Notice 36 Copyright (C) William Allen Simpson (1998-1999). All Rights 37 Reserved. 39 Abstract 41 "The PPP DES Encryption Protocol" [RFC-2419], "The ESP DES-CBC Cipher 42 Algorithm With Explicit IV" [RFC-2405], and "The ESP DES-CBC 43 Transform" [RFC-1829] have been re-classified to Historic status, and 44 implementation is Not Recommended. 46 "The PPP Triple-DES Encryption Protocol (3DESE)" [RFC-2420] and "The 47 ESP Triple-DES Transform" [RFC-xxxx] are now classified as mandatory 48 to implement for Standards Track interoperability. 50 This Applicability Statement provides the supporting motivation for 51 that classification. The primary reason is that DES alone provides 52 insufficient strength for the protection of moderate value 53 information for any length of time. 55 1. Introduction 57 The US Data Encryption Standard (DES) algorithm [FIPS-46] has had a 58 long history of analysis since its adoption in 1977. At the time of 59 RFC-1829 publication in 1995, briefly citing the current analysis and 60 describing known limitations, it was suggested that DES was not a 61 good algorithm for the protection of moderate value information. 62 However, the level of confidentiality provided by the use of DES in 63 the Internet environment was considered greater than sending the 64 datagrams as cleartext. 66 Recently, RSA Data Security has issued a series of challenges to 67 demonstrate the current effectiveness of various algorithms and key 68 lengths. Each challenge has a shorter time for completion. 70 The first DES challenge of January, 1997, was solved in 140 days (on 71 June 17, 1997), after searching only 25% of the key space. On 72 average, half of the key space can be expected to be searched. Much 73 of the time was spent organizing competing volunteer efforts. The 74 hidden message was "Strong cryptography makes the world a safer 75 place." 77 The DES challenge of January, 1998, was solved in 40 days (on 78 February 23, 1998), after searching over 88% of the key space using 79 tens of thousands of Internet hosts in their spare time. The hidden 80 message was "Many hands make light work." 82 The DES challenge of July 13, 1998, was solved on July 16, 1998, 83 after only 2.5 days (56 hours)! The winner was a single purpose 84 built machine, "Deep Crack", sponsored by Electronic Frontier 85 Foundation (EFF) [EFF98]. The hidden message was "It's time for 86 those 128-, 192-, and 256-bit keys." 88 This demonstrated that the cost of deploying and maintaining Internet 89 firewalls and Virtual Private Networks can easily exceed the cost of 90 recovering DES protected confidential data. For protection against 91 governmental or industrial espionage, the use of DES in the Internet 92 environment no longer has any cost benefit over sending the datagrams 93 as cleartext. 95 The DES challenge of January 19, 1999, was solved in only 22 hours 96 and 15 minutes! The winner was the EFF "Deep Crack" working together 97 with the distributed volunteer network. The hidden message was "See 98 you in Rome (second AES Conference, March 22-23, 1999)." 100 The Advanced Encryption Standard (AES) initiative proposes replacing 101 the obsolete 56-bit DES with one or more algorithms using encryption 102 keys of at least 128-bits. 104 2. Problems 106 DES has a number of problems that restrict its usability in the 107 global Internet. 109 2.1. Key Length 111 Even at the time of DES publication, the analytic community 112 questioned the DES 56-bit key length as insufficient for long-term 113 use [DH77]. In 1987, the US National Security Administration raised 114 objections to re-certifying DES as a US Federal Information 115 Processing Standard [SB88]. Never-the-less, after much discussion, 116 DES was re-certified [FIPS46-1], and again in 1993. 118 The DES certification expires in 1998, and the US has begun a public 119 process, the Advanced Encryption Standard (AES) initiative, for 120 evaluating replacements with longer key lengths. This successor 121 requires 128-, 192-, and 256-bit key lengths. 123 Numerous studies have predicted the work factor of various key 124 lengths, and the trade-offs between cost, memory, and time. See 125 [Schneier95, Chapter 7], which recommends a minimum of 112-bit keys, 126 and shows that 128-bit keys would be immune to parallel computation 127 by conventional computer equipment and recovery of 256-bit keys might 128 be limited by the energy available in the solar system. 130 The most recent analysis for symmetric keys [BDRSSTW96] empirically 131 estimated that a minimum of 75-bit keys would be required in the 132 short-term, and strongly recommends a minimum of 90-bit keys for 133 future long-term standards. Correspondence with some of those 134 authors has indicated that these estimates should rise a few bits to 135 reflect subsequent increases in computational power. 137 Taking these recommendations together yields a range of 80-bit keys 138 for short term use, 128-bit keys for longer term use, and 256-bit 139 keys as standards evolve. 141 2.2. Recovery Time 143 Shortly after DES publication, the analytic community predicted a 144 purpose-built DES cracking machine could be built for 10 to 20 145 million US Dollars that would recover a key within 1 to 2 days [DH77, 146 Hellman79, Diffie81]. More recently, [Weiner94] sketched the design 147 of a DES cracking machine for 1 million US Dollars that would recover 148 a key in an average of 3.5 hours. These costs were within the reach 149 of most governments and large organizations. Anecdotal evidence 150 suggests that some governments may have built such a machine. 152 The progression of the RSA challenges anticipated that the 153 distributed software network could finish the third challenge in 10 154 days. A recent paper [BDRSSTW96] estimated that a relatively 155 inexpensive "off-the-shelf technology" 300 thousand US Dollar DES 156 cracking machine would recover a key in an average of 19 days. 158 It turns out that these estimates were too high. The EFF was able to 159 build an operating DES cracking machine for under 250 thousand US 160 Dollars [EFF98]. The device, known as "Deep Crack", completed the 161 DES challenge in only 2.5 days. This level of expenditure is well 162 within the reach of even small organizations, and the EFF effort has 163 shown that the curve of cost versus time has advanced more rapidly 164 than had been predicted. 166 It has been suggested that DES might still be useful for short-lived 167 data. This assumption is unwarranted. Adversaries with relatively 168 small budgets will soon have the capability to recover 56-bit keys in 169 hours or minutes. Well-financed adversaries have or will soon have 170 the capability to recover any DES key within seconds. 172 2.3. Value 174 The specifications for the EFF DES cracking machine have been 175 published [EFF98]. Additional machines can be built for the same or 176 lower cost. Assuming that a DES cracking machine has a useful 177 service lifetime of 3 or more years, the amortized cost of recovering 178 any single key is less than 1,200 US Dollars. This is significantly 179 less than the value of common consumer transactions. 181 Morever, the cost of deploying and maintaining Internet firewalls and 182 Virtual Private Networks utilizing long-term manually configured DES 183 keys is considerably greater than 1,200 US Dollars per key. 185 Furthermore, confidential communications and archival data of any 186 significant value that was protected by DES have become a ripe target 187 for key recovery. It is frequently impractical to convert the 188 archival data to a more robust algorithm. There can be no assurance 189 that all DES copies have been destroyed, and that none have been 190 intercepted or compromised. 192 There is no comparative advantage, and significant economic 193 disadvantage, in continuing to use the single-DES algorithm. A 194 number of other algorithms are likely to provide significantly higher 195 protection for valuable information, at a cost very close to that of 196 DES. 198 3. Conclusions and Recommendations 200 Currently deployed equipment using DES should be eliminated, or 201 upgraded to a more robust algorithm and key length. 203 Existing data depending upon DES for confidentiality should be 204 considered potentially compromised. 206 Key lengths less than 80 bits are not acceptable for use in future 207 standards and not recommended for use in the Internet for protecting 208 short-lived Internet data. Communication protocols with less 209 strength must not be advanced on the Internet Standards Track. 211 Key lengths less than 128 bits are not recommended for protecting 212 long-lived Internet data. Message and storage protocols with less 213 strength should not be advanced on the Internet Standards Track. 215 "The PPP DES Encryption Protocol" [RFC-2419], "The ESP DES-CBC Cipher 216 Algorithm With Explicit IV" [RFC-2405], and "The ESP DES-CBC 217 Transform" [RFC-1829] have been re-classified to Historic status, and 218 implementation is Not Recommended. 220 "The PPP Triple-DES Encryption Protocol (3DESE)" [RFC-2420] and "The 221 ESP Triple-DES Transform" [RFC-xxxx] are now classified as mandatory 222 to implement for Standards Track interoperability. 224 Security Considerations 226 Security issues are the topic of this entire document. 228 Users need to understand that the quality of the security provided 229 depends completely on the strength of the algorithm, the correctness 230 of that algorithm's implementation, the security of the Security 231 Association management mechanism and its implementation, the strength 232 of the key [CN94], and upon the correctness of the implementations in 233 all of the participating nodes. 235 History 237 On July 20, 1998, William Allen Simpson, with the concurrance of 238 Perry Metzger and Phil Karn, asked that their DES encryption Proposed 239 Standard [RFC-1829], and the related PPP DES encryption Proposed 240 Standard [RFC-1619], be declared Historic (removed from the Standards 241 Track), and recommended DESX and Triple-DES as interim Proposed 242 Standards until the selection of AES. With the assistance of Scott 243 Bradner, this Applicability Statement was written to reflect the 244 recommendation. 246 Instead, the IESG approved RFC-2405 and RFC-2419 for publication as 247 Proposed Standards in November and September, 1998, respectively. 249 On March 18, 1999, the Security Area Advisory Group overwhelmingly 250 approved removal of DES from the Standards Track, and recommended 251 Triple-DES as mandatory to implement. This Applicability Statement 252 was updated to reflect the recommendation. 254 Acknowledgements 256 John Gilmore provided useful critiques of earlier versions of this 257 document. 259 References 261 [BDRSSTW96] Blaze, M., Diffie, W., Rivest, R., Schneier, B., 262 Shimomura, T., Thompson, E., and Weiner, M., "Minimal Key 263 Lengths for Symmetric Ciphers to Provide Adequate 264 Commercial Security", 265 ftp://ftp.research.att.com/dist/mab/keylength, January 266 1996. 268 [CN94] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak 269 Data: Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 270 23 pp. 253-280, July 1994. 272 [DH77] Diffie, W., and Hellman, M.E., "Exhaustive Cryptanalysis 273 of the NBS Data Encryption Standard", Computer, v 10 n 6, 274 June 1977. 276 [Diffie81] Diffie, W., "Cryptographic Technology: Fifteen Year 277 Forecast", BNR Inc., January 1981. 279 [EFF98] Electronic Frontier Foundation, Gilmore, J., Editor, 280 "Cracking DES: Secrets of Encryption Research, Wiretap 281 Politics, and Chip Design", O'Reilly and Associates, July 282 1998. 284 [FIPS-46] US National Bureau of Standards, "Data Encryption 285 Standard", Federal Information Processing Standard (FIPS) 286 Publication 46, January 1977. 288 [FIPS-46-1] US National Bureau of Standards, "Data Encryption 289 Standard", Federal Information Processing Standard (FIPS) 290 Publication 46-1, January 1988. 292 [Hellman79] Hellman, M.E., "DES Will Be Totally Insecure within Ten 293 Years", IEEE Spectrum, v 16 n 7, July 1979. 295 [RFC-1829] Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC 296 Transform", July 1995. 298 [RFC-2405] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher 299 Algorithm With Explicit IV", November 1998. 301 [RFC-2419] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, 302 Version 2 (DESE-bis)", September 1998. 304 [RFC-2420] Kummert, H., "The PPP Triple-DES Encryption Protocol 305 (3DESE)", September 1998. 307 [RFC-xxxx] Simpson, W., Metzger, P., Karn, P., Doraswamy, N., "The 308 ESP Triple-DES Transform", Work In Progress, July 1998. 310 [SB88] Smid, M.E., and Branstad, D.K., "The Data Encryption 311 Standard: Past and Future", Proceedings of the IEEE, v 76 312 n 5, May 1988. 314 [Schneier95] 315 Schneier, B., "Applied Cryptography Second Edition", John 316 Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. 318 [Weiner94] Wiener, M.J., "Efficient DES Key Search", School of 319 Computer Science, Carleton University, Ottawa, Canada, 320 TR-244, May 1994. Presented at the Rump Session of 321 Crypto '93. 323 Contacts 325 Comments about this document should be discussed on the ietf@ietf.org 326 mailing list. 328 Questions about this document can also be directed to: 330 William Allen Simpson 331 DayDreamer 332 Computer Systems Consulting Services 333 1384 Fontaine 334 Madison Heights, Michigan 48071 336 wsimpson@UMich.edu 337 wsimpson@GreenDragon.com (preferred) 339 Scott Bradner 340 Harvard University 341 1350 Mass Ave, Room 876 342 Cambridge, Massachusetts 02138 344 sob@harvard.edu 346 Full Copyright Statement 348 Copyright (C) William Allen Simpson (1998-1999). All Rights 349 Reserved. 351 This document and translations of it may be copied and furnished to 352 others, and derivative works that comment on or otherwise explain it 353 or assist in its implementation may be prepared, copied, published 354 and distributed, in whole or in part, without restriction of any 355 kind, provided that the above copyright notice and this paragraph are 356 included on all such copies and derivative works. However, this 357 document itself may not be modified in any way, except as required to 358 translate it into languages other than English. 360 This document and the information contained herein is provided on an 361 "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR 362 IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF 363 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 364 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.