idnits 2.17.1 draft-ietf-saag-aes-ciph-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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. 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 1999) is 9021 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 section? '1' on line 130 looks like a reference -- Missing reference section? '2' on line 204 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jeffrey I. Schiller 2 Internet Draft MIT 4 Expiration Date: January 2000 August 1999 6 Cryptographic Algorithms for the IETF 8 draft-ietf-saag-aes-ciph-00.txt 10 1. 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. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 2. Abstract 33 Today the IETF recommends, and in some places requires the 34 implementation of the U.S. Data Encryption Standard (DES). This 35 choice was made a number of years ago with the assumption that DES 36 represented an unbreakable cipher. Recent work has shown this 37 assumption to no longer be the case. Therefore this document 38 discusses what alternatives and directions are available to the IETF. 40 3. Introduction 42 The design of encryption algorithms requires significant skill and 43 training. It is beyond the scope and competence of the IETF to design 44 such algorithms. Instead the IETF should and does make use of 45 generally accepted algorithms in the industry. For many years the 46 algorithm of choice for security was the U.S. Data Encryption 47 Standard (DES). DES makes use of a 56 bit key and works on blocks of 48 data which are 64 bits in length (8 bytes). The DES is a U.S. 49 National Standard. 51 Recent work in the cryptographic community, particularly the 52 construction of "Deep Crack" by the Electronic Frontier Foundation 53 has made it clear that a 56 bit cipher is no longer acceptable for 54 strong security. The Deep Crack engine can recover a DES key in as 55 little as 24 hours. 57 In general a strong cipher, as used by the IETF, is one in which 58 recovery of keys or enciphered data (without the key) is 59 computationally infeasible with both existing technology, and 60 technology that is projected to exist within approximately ten years 61 of the selection of a suitable algorithm. 63 Because DES no longer meets this requirement, we need to select an 64 alternative set of ciphers. 66 4. The Advanced Encryption Standard 68 The U.S. National Institute of Standards and Technology (NIST) has 69 undertaken the Advanced Encryption Standard (AES) Project. This 70 project called for cryptographers world-wide to submit ciphers to be 71 considered as a replacement national (U.S.) standard for the DES. The 72 AES project set out several criteria for consideration for the 73 standard. Of particular interest to the IETF is that this new 74 standard will operate on 128 bit blocks of data instead of the 64 bit 75 blocks of data operated on by the DES and similar ciphers. 77 As of this writing NIST has selected 5 candidate from an original set 78 of 15 submissions. However it may not be until sometime in 2000 or 79 2001 before a final algorithm, or set of algorithms is chosen. 81 Submitters to the AES process had to agree that they would make their 82 proposed cipher available free of charge if their proposal was 83 selected as the final standard. However they are not required to do 84 so if they are not selected nor are they required to do so prior to 85 the final selection. 87 However, several submitters have already stated their intention of 88 making their cipher available for public use prior to the final NIST 89 selection. 91 5. IETF Requirements 93 The Security Area Advisory Group (SAAG) of the IETF has considered 94 the requirements for IETF selected ciphers. They are: 96 1. Strength: The IETF should standardize the use of "strong" ciphers 97 which cannot be compromised either using today's best technology nor 98 tomorrow's best technology (10 years, for example) based on 99 reasonable projections of the evolution of computing technology. 101 2. Key Length of at least 128 bits: This criteria is related to the 102 strength of the cipher. However even strong ciphers may support 103 several different key lengths. For the use of the IETF in a 104 "mandatory to implement" [1] cipher keys of at least 128 bits must be 105 supported. 107 3. Is freely available: There should be no requirement for licensing 108 or other intellectual property constraints. 110 4. Performance: Many IETF protocols have to operate at high speed. 111 Cryptographic processing may need to be quick. 113 6. Meeting the Requirements 115 The obvious candidate from a security perspective is to use "Triple 116 DES" (3DES). 3DES is the literal application of the DES cipher three 117 time instead of simply once. Today the DES cipher has proven to be 118 strong. Since its introduction in the 1970's it has been actively 119 attacked without significant success. The primary problem with DES 120 today is that its key length of 56 bits makes it vulnerable to the 121 brute force search of all possible keys. This is what the Deep Crack 122 engine performs. 124 However, invoking the DES algorithm three times increases the 125 effective key length from 56 bits to 168 bits. This eliminates the 126 brute force attack. 128 The advantage to this approach is that 3DES is fundamentally a 129 ----------- 130 [1] In order to foster interoperation the IETF requires 131 that at least one cipher be required to be implemented in a 132 standards conforming implementation of a protocol. 134 version of DES and DES has been subject to over two decades of 135 scrutiny by scores of cryptanalysts worldwide. No practical 136 cryptanalytic attack has ever been published, leaving brute force as 137 the only practical attack mechanism. 139 In March of 1999 at the Minneapolis IETF meeting, the consensus of 140 the SAAG was that we should use 3DES as the mandatory to implement 141 cipher. Working groups in the Security Area of the IETF are advised 142 to update working documents to specify 3DES as the mandatory cipher. 144 7. Should there be an additional Cipher? 146 3DES has one significant problem, its performance is 3 times slower 147 then DES and DES was never designed to be fast in software. The 148 result is that our performance requirement is not being met in many 149 compute-constrained environments. 151 At the SAAG meeting in July of 1999 at the Oslo IETF meeting we 152 discussed the notion of specifying an additional mandatory cipher. 153 3DES would remain as the "safe but slow choice" and the additional 154 cipher would primarily be used in areas where performance is an 155 issue. 157 However, selecting an additional cipher is a difficult problem at 158 this time. If the AES project had already concluded, our choice would 159 be easy, we would choose the AES selected cipher. However the AES 160 project has not yet completed, so we need to choose from the 161 candidates. 163 Today there are 5 candidates; the first round AES finalists. We could 164 easily choose one of these five. 166 However there was no consensus to do so at the meeting. For the time 167 being, the IETF should not specify an additional mandatory cipher. 169 8. The Consensus 171 We did have consensus that we would likely choose an additional 172 cipher at some future time, perhaps after the AES cipher is selected. 173 There was pretty clear consensus that we should choose an AES cipher. 175 9. Choosing an AES Cipher 177 The AES program specifies that the successful cipher will operate on 178 128 bit blocks instead of the 64 bit blocks that DES (and 3DES) makes 179 use of today. Supporting this will likely require implementers to 180 change their code. Therefore we conclude that given the likelihood of 181 the IETF specifying an AES cipher as mandatory, that implementers 182 would be wise to consider the necessary changes to their software to 183 support 128 bit ciphers in the future. 185 10. Issues Relating to Key Length 187 The AES program specifies a cipher that will operate on keys of 188 length 128 bits, 192 bits and 256 bits. Although the IETF will likely 189 only require the support of keys of 128 bits (which should be 190 sufficient for the foreseeable future) it is likely that implementers 191 will wish to make use of the longer key lengths possible with the 192 AES. 194 We had a brief discussion at the SAAG meeting about the implications 195 that arise from this. Specifically if we start using keys longer then 196 128 bits, we have to consider the impact that we have on the 197 asymmetric key management ciphers and protocols that we are 198 standardizing today. It is likely that these will need to be modified 199 to provide additional cryptographic strength to match the additional 200 cryptographic strength of an AES cipher using a key length of greater 201 then 128 bits. [2] 203 ----------- 204 [2] Frankly we can easily use longer keys while NOT chang- 205 ing the key exchange algorithms and key lengths. However we 206 would not be offering the true security implied by the 207 longer symmetric algorithm key length as the asymmetric por- 208 tion of the protocol would become the weak link. 210 11. Conclusions 212 We have IETF consensus that we should phase out the use of ciphers 213 whose key lengths are less then 128 bits. This implies that we should 214 deprecate the use of DES when possible. For most protocols this means 215 that we will mandate the use of 3DES for the foreseeable future. We 216 are discussing the addition of a second mandatory to implement 217 cipher, but do not yet have consensus on this. 219 Although we are deprecating the use of DES (and similar short key 220 ciphers) we are not requiring that they must not be supported. DES 221 and other algorithms can continue to be implemented in optional 222 mechanisms and as optional additional ciphers. 224 12. Acknowledgments 226 The author would like to thank Marcus Leech for detailed reading and 227 editing. This document reflects a discussion held at the Security 228 Area Advisory Group meeting at the 45th IETF meeting held in Oslo 229 during July of 1999. I would therefore like to acknowledge the 230 members of the SAAG who contributed to this discussion. 232 13. Author's Information 234 Jeffrey I. Schiller 235 MIT Room E40-311 236 77 Massachusetts Avenue 237 Cambridge, MA 02139-4307 USA 238 Phone: +1 (617) 253-0161 239 E-mail: jis@mit.edu 241 Comments on this draft should be sent to: saag@lists.tislabs.com, the 242 SAAG mailing list.