idnits 2.17.1 draft-simpson-des-as-00.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-23) 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 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-1829], [RFC-1969]), 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 (August 1998) is 9383 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: 'RFC-1829' is mentioned on line 42, but not defined == Missing Reference: 'RFC-1969' is mentioned on line 43, but not defined ** Obsolete undefined reference: RFC 1969 (Obsoleted by RFC 2419) == Missing Reference: 'FIPS46-1' is mentioned on line 100, but not defined == Missing Reference: 'Chapter 7' is mentioned on line 108, but not defined == Unused Reference: 'Diffie81' is defined on line 223, but no explicit reference was found in the text == Unused Reference: 'FIPS-46-1' is defined on line 235, but no explicit reference was found in the text == Unused Reference: 'Hellman79' is defined on line 239, 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. 'SB88' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Weiner94' Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W A Simpson [DayDreamer] 3 Internet Draft S Bradner [Harvard University] 4 expires in six months August 1998 6 DES Applicability Statement for Historic Status 7 draft-simpson-des-as-00.txt 9 Status of this Memo 11 This document is an Internet-Draft. Internet Drafts are working doc- 12 uments of the Internet Engineering Task Force (IETF), its Areas, and 13 its Working Groups. Note that other groups may also distribute work- 14 ing documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months, and may be updated, replaced, or obsoleted by other documents 18 at any time. It is not appropriate to use Internet Drafts as refer- 19 ence material, or to cite them other than as a ``working draft'' or 20 ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 24 Directories on: 26 ftp.is.co.za (Africa) 27 nic.nordu.net (Northern Europe) 28 ftp.nis.garr.it (Southern Europe) 29 ftp.ietf.org (Eastern USA) 30 ftp.isi.edu (Western USA) 31 munnari.oz.au (Pacific Rim) 33 Distribution of this memo is unlimited. 35 Copyright Notice 37 Copyright (C) William Allen Simpson and Scott Bradner (1998). All 38 Rights Reserved. 40 Abstract 42 "The ESP DES-CBC Transform" [RFC-1829] and "The PPP DES Encryption 43 Protocol" [RFC-1969] have been re-classified to Historic status, and 44 implementation is Not Recommended. This Applicability Statement pro- 45 vides the supporting motivation for that classification. The primary 46 reason is that DES alone provides insufficient strength for the pro- 47 tection of moderate value information for any length of time. 49 1. Introduction 51 The US Data Encryption Standard (DES) algorithm [FIPS-46] has had a 52 long history of analysis since its adoption in 1977. At the time of 53 RFC-1829 publication in 1995, briefly citing the current analysis and 54 describing known limitations, it was suggested that DES was not a 55 good algorithm for the protection of moderate value information. 56 However, the level of confidentiality provided by the use of DES in 57 the Internet environment was considered greater than sending the 58 datagrams as cleartext. 60 Recently, RSA Data Security has issued a series of challenges to 61 demonstrate the current effectiveness of various algorithms and key 62 lengths. Each challenge has a shorter time for completion. 64 The first DES challenge of January, 1997, was solved in 140 days on 65 June 17, 1997, after searching only 25% of the key space. On aver- 66 age, half of the key space can be expected to be searched. Much of 67 the time was spent organizing competing volunteer efforts. The hid- 68 den message was "Strong cryptography makes the world a safer place." 70 The second DES challenge of January 13, 1998, was solved in 40 days 71 on February 23, 1998, after searching over 88% of the key space using 72 tens of thousands of Internet hosts in their spare time. The hidden 73 message was "Many hands make light work." 75 The third DES challenge of July 13, 1998, was solved on July 16, 76 1998, after only 2.5 days! The winner was a single purpose built 77 machine sponsored by Electronic Frontier Foundation (EFF) [EFF98]. 78 The hidden message was "It's time for those 128-, 192-, and 256-bit 79 keys." 81 This demonstrated that the cost of deploying and maintaining Internet 82 firewalls and Virtual Private Networks can easily exceed the cost of 83 recovering DES protected confidential data. For protection against 84 governmental or industrial espionage, the use of DES in the Internet 85 environment no longer has any cost benefit over sending the datagrams 86 as cleartext. 88 2. Problems 90 DES has a number of problems that restrict its usability in the 91 global Internet. 93 2.1. Key Length 95 Even at the time of DES publication, the analytic community ques- 96 tioned the DES 56-bit key length as insufficient for long-term use 97 [DH77]. In 1987, the US National Security Administration raised 98 objections to re-certifying DES as a US Federal Information Process- 99 ing Standard [SB88]. Never-the-less, after much discussion, DES was 100 re-certified [FIPS46-1], and again in 1993. 102 The DES certification expires in 1998, and the US has begun a public 103 process for evaluating replacements with longer key lengths. This 104 successor requires 128-, 192-, and 256-bit key lengths. 106 Numerous studies have predicted the work factor of various key 107 lengths, and the trade-offs between cost, memory, and time. See 108 [Schneier95, Chapter 7], which recommends a minimum of 112-bit keys, 109 and shows that 128-bit keys would be immune to parallel computation 110 by conventional computer equipment and recovery of 256-bit keys might 111 be limited by the energy available in the solar system. 113 The most recent analysis for symmetric keys [BDRSSTW96] empirically 114 estimated that a minimum of 75-bit keys would be required in the 115 short-term, and strongly recommends a minimum of 90-bit keys for 116 future long-term standards. 118 2.2. Recovery Time 120 Shortly after DES publication, the analytic community predicted a 121 purpose-built DES cracking machine could be built for 10 to 20 mil- 122 lion US Dollars that would recover a key within 1 to 2 days [DH77, 123 Hellman79, Diffie81]. More recently, [Weiner94] sketched the design 124 of a DES cracking machine for 1 million US Dollars that would recover 125 a key in an average of 3.5 hours. These costs were within the reach 126 of most governments and large organizations. Anecdotal evidence sug- 127 gests that some governments may have built such a machine. 129 The progression of the RSA challenges anticipated that the dis- 130 tributed software network could finish the third challenge in 10 131 days. A recent paper [BDRSSTW96] estimated that a relatively inex- 132 pensive "off-the-shelf technology" 300 thousand US Dollar DES crack- 133 ing machine would recover a key in an average of 19 days. 135 Instead, the cost of the non-recurrent engineering and first proto- 136 type for the EFF DES cracking machine was under 250 thousand US Dol- 137 lars [EFF98], and it completed the challenge in 2.5 days. This is 138 well within the reach of even small organizations, and has shown that 139 the curve of cost versus time has advanced more rapidly than pre- 140 dicted. 142 It has been suggested that DES might still be useful for short-lived 143 data. This assumption is unwarranted. Attackers with relatively 144 small budgets will soon have the capability to recover 56-bit keys in 145 hours or minutes. Well-financed attackers have or will soon have the 146 capability to recover any DES key within seconds. 148 2.3. Value 150 The specifications for the EFF DES cracking machine have been pub- 151 lished [EFF98]. Additional machines can be built for the same or 152 lower cost. Assuming that a DES cracking machine has a useful ser- 153 vice lifetime of 3 or more years, the amortized cost of recovering 154 any single key is less than 1,200 US Dollars. This is significantly 155 less than the value of common consumer transactions. 157 Morever, the cost of deploying and maintaining Internet firewalls and 158 Virtual Private Networks utilizing long-term manually configured DES 159 keys is considerably greater than 1,200 US Dollars per key. 161 Furthermore, confidential communications and archival data of any 162 significant value that was protected by DES have become a ripe target 163 for key recovery. It is frequently impractical to convert the 164 archival data to a more robust algorithm. There can be no assurance 165 that all DES copies have been destroyed, and that none have been 166 intercepted or compromised. 168 There is no comparative advantage, and significant economic disadvan- 169 tage, in continuing to use the single-DES algorithm. A number of 170 other algorithms are likely to provide significantly higher protec- 171 tion for valuable information, at a cost very close to that of DES. 173 3. Conclusions and Recommendations 175 Currently deployed equipment using DES should be eliminated, or 176 upgraded to a more robust algorithm and key length. 178 Existing data depending upon DES for confidentiality should be con- 179 sidered potentially compromised. 181 Key lengths less than 80 bits are not acceptable for use in future 182 standards and not recommended for use in the Internet for protecting 183 short-lived Internet data. Communication protocols with less 184 strength will not be advanced on the Internet Standards Track. 186 Key lengths less than 128 bits are not recommended for protecting 187 long-lived Internet data. Message and storage protocols with less 188 strength should not be advanced on the Internet Standards Track. 190 Security Considerations 192 Security issues are the topic of this entire document. 194 Users need to understand that the quality of the security provided 195 depends completely on the strength of the algorithm, the correctness 196 of that algorithm's implementation, the security of the Security 197 Association management mechanism and its implementation, the strength 198 of the key [CN94], and upon the correctness of the implementations in 199 all of the participating nodes. 201 Acknowledgements 203 John Gilmore provided useful critiques of earlier versions of this 204 document. 206 References 208 [BDRSSTW96] Blaze, M., Diffie, W., Rivest, R., Schneier, B., Shimo- 209 mura, T., Thompson, E., and Weiner, M., "Minimal Key 210 Lengths for Symmetric Ciphers to Provide Adequate Commer- 211 cial Security", 212 ftp://ftp.research.att.com/dist/mab/keylength, January 213 1996. 215 [CN94] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak 216 Data: Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 217 23 pp. 253-280, July 1994. 219 [DH77] Diffie, W., and Hellman, M.E., "Exhaustive Cryptanalysis 220 of the NBS Data Encryption Standard", Computer, v 10 n 6, 221 June 1977. 223 [Diffie81] Diffie, W., "Cryptographic Technology: Fifteen Year Fore- 224 cast", BNR Inc., January 1981. 226 [EFF98] Electronic Frontier Foundation, Gilmore, J., Editor, 227 "Cracking DES: Secrets of Encryption Research, Wiretap 228 Politics, and Chip Design", O'Reilly and Associates, July 229 1998. 231 [FIPS-46] US National Bureau of Standards, "Data Encryption Stan- 232 dard", Federal Information Processing Standard (FIPS) 233 Publication 46, January 1977. 235 [FIPS-46-1] US National Bureau of Standards, "Data Encryption Stan- 236 dard", Federal Information Processing Standard (FIPS) 237 Publication 46-1, January 1988. 239 [Hellman79] Hellman, M.E., "DES Will Be Totally Insecure within Ten 240 Years", IEEE Spectrum, v 16 n 7, July 1979. 242 [SB88] Smid, M.E., and Branstad, D.K., "The Data Encryption 243 Standard: Past and Future", Proceedings of the IEEE, v 76 244 n 5, May 1988. 246 [Schneier95] 247 Schneier, B., "Applied Cryptography Second Edition", John 248 Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. 250 [Weiner94] Wiener, M.J., "Efficient DES Key Search", School of Com- 251 puter Science, Carleton University, Ottawa, Canada, 252 TR-244, May 1994. Presented at the Rump Session of 253 Crypto '93. 255 Contacts 257 Comments about this document should be discussed on the ietf@ietf.org 258 mailing list. 260 Questions about this document can also be directed to: 262 William Allen Simpson 263 DayDreamer 264 Computer Systems Consulting Services 265 1384 Fontaine 266 Madison Heights, Michigan 48071 268 wsimpson@UMich.edu 269 wsimpson@GreenDragon.com (preferred) 271 Scott Bradner 272 Harvard University 273 1350 Mass Ave, Room 876 274 Cambridge, Massachusetts 02138 276 sob@harvard.edu 278 Full Copyright Statement 280 Copyright (C) William Allen Simpson and Scott Bradner (1998). All 281 Rights Reserved. 283 This document and translations of it may be copied and furnished to 284 others, and derivative works that comment on or otherwise explain it 285 or assist in its implementation may be prepared, copied, published 286 and distributed, in whole or in part, without restriction of any 287 kind, provided that the above copyright notice and this paragraph are 288 included on all such copies and derivative works. However, this doc- 289 ument itself may not be modified in any way, except as required to 290 translate it into languages other than English. 292 This document and the information contained herein is provided on an 293 "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR 294 IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF 295 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 296 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.