idnits 2.17.1 draft-ietf-tls-des-idea-02.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 220. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 231. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 238. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 244. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 25, 2008) is 5776 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCnnnn' is mentioned on line 144, but not defined ** Obsolete normative reference: RFC 2246 (ref. 'TLS10') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4346 (ref. 'TLS11') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 5246 (ref. 'TLS12') (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group P. Eronen, Ed. 3 Internet-Draft Nokia 4 Intended status: Informational June 25, 2008 5 Expires: December 27, 2008 7 DES and IDEA Cipher Suites for Transport Layer Security (TLS) 8 draft-ietf-tls-des-idea-02.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 December 27, 2008. 35 Abstract 37 TLS specification versions 1.0 (RFC 2246) and 1.1 (RFC 4346) included 38 cipher suites based on DES (Data Encryption Standard) and IDEA 39 (International Data Encryption Algorithm) algorithms. DES (when used 40 in single-DES mode) and IDEA are no longer recommended for general 41 use in TLS, and have been removed from TLS 1.2 main specification 42 (RFC 5246). This document specifies these cipher suites for 43 completeness, and discusses reasons why their use is no longer 44 recommended. 46 1. Introduction 48 TLS specification versions 1.0 [TLS10] and 1.1 [TLS11] included 49 cipher suites based on DES (Data Encryption Standard) and IDEA 50 (International Data Encryption Algorithm) algorithms. DES (when used 51 in single-DES mode) and IDEA are no longer recommended for general 52 use in TLS, and have been removed from TLS 1.2 main specification 53 [TLS12]. 55 This document specifies these cipher suites for completeness, and 56 discusses reasons why their use is no longer recommended. 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in [REQ]. 62 2. DES Cipher Suites 64 DES (Data Encryption Standard) is a block cipher which was originally 65 approved as US federal standard in 1976, and is specified in [DES]. 67 For TLS key generation purposes, DES is treated as having a 64-bit 68 key, but it still provides only 56 bits of protection, as 8 of the 64 69 bits are not used by the algorithm. DES uses a 64-bit block size. 71 The following cipher suites have been defined for using DES in CBC 72 mode in TLS: 74 CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; 75 CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C }; 76 CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F }; 77 CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 }; 78 CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }; 79 CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; 81 The key exchange algorithms (RSA, DH_DSS, DH_RSA, DHE_DSS, DHE_RSA, 82 and DH_anon) and the MAC algorithm (SHA) are defined in the base TLS 83 specification. 85 3. IDEA Cipher Suite 87 IDEA (International Data Encryption Algorithm) is a block cipher 88 designed by Xuejia Lai and James Massey [IDEA] [SCH]. IDEA uses a 89 128-bit key and operates on 64-bit blocks. 91 The following cipher suite has been defined for using IDEA in CBC 92 mode in TLS: 94 CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; 96 The key exchange algorithm (RSA) and the MAC algorithm (SHA) are 97 defined in the base TLS specification. 99 4. Security Considerations 101 4.1. DES Cipher Suites 103 DES has an effective key strength of 56 bits, which has been been 104 known to be vulnerable to practical brute force attacks for over 20 105 years [DH]. A relatively recent 2006 paper by Kumar et al. [COPA] 106 describes a system which performs exhaustive key search in less than 107 nine days on average, and costs less than 10,000 USD to build. 109 Given this, the single-DES cipher suites SHOULD NOT be implemented by 110 TLS libraries. If a TLS library implements these cipher suites, it 111 SHOULD NOT enable them by default. Experience has also shown that 112 rarely used code is a source of security and interoperability 113 problems, so existing implementations SHOULD consider removing these 114 cipher suites. 116 4.2. IDEA Cipher Suite 118 IDEA has a 128-bit key, and thus is not vulnerable to exhaustive key 119 search. However, the IDEA cipher suite for TLS has not seen 120 widespread use: most implementations either do not support it, do not 121 enable it by default, or do not negotiate it when other algorithms 122 (such as AES, 3DES, or RC4) are available. 124 Experience has shown that rarely used code is a source of security 125 and interoperability problems; given this, the IDEA cipher suite 126 SHOULD NOT be implemented by TLS libraries, and SHOULD be removed 127 from existing implementations. 129 5. IANA Considerations 131 IANA has already allocated values for the cipher suites described in 132 this document in the TLS Cipher Suite Registry, defined in [TLS11]. 133 IANA is requested to update (has updated) the references of these 134 cipher suites to point to this document: 136 Value Description Reference 137 ----------- -------------------------------------- --------- 138 0x00,0x07 TLS_RSA_WITH_IDEA_CBC_SHA [RFCnnnn] 139 0x00,0x09 TLS_RSA_WITH_DES_CBC_SHA [RFCnnnn] 140 0x00,0x0C TLS_DH_DSS_WITH_DES_CBC_SHA [RFCnnnn] 141 0x00,0x0F TLS_DH_RSA_WITH_DES_CBC_SHA [RFCnnnn] 142 0x00,0x12 TLS_DHE_DSS_WITH_DES_CBC_SHA [RFCnnnn] 143 0x00,0x15 TLS_DHE_RSA_WITH_DES_CBC_SHA [RFCnnnn] 144 0x00,0x1A TLS_DH_anon_WITH_DES_CBC_SHA [RFCnnnn] 146 This document does not create any new registries to be maintained by 147 IANA, and does not require any new assignments from existing 148 registries. 150 6. Acknowledgments 152 The editor would like to thank Steven Bellovin, Uri Blumenthal, 153 Michael D'Errico, Paul Hoffman, Simon Josefsson, Bodo Moeller, Tom 154 Petch, Martin Rex, and Len Sassaman for their contributions to 155 preparing this document. 157 7. References 159 7.1. Normative References 161 [DES] National Institute of Standards and Technology, "Data 162 Encryption Standard (DES)", FIPS PUB 46-3, October 1999. 164 [IDEA] Lai, X., "On the Design and Security of Block Ciphers", 165 ETH Series in Information Processing, v. 1, Konstanz: 166 Hartung-Gorre Verlag, 1992. 168 [REQ] Bradner, S., "Key words for use in RFCs to Indicate 169 Requirement Levels", BCP 14, RFC 2119, March 1997. 171 [SCH] Schneier, B., "Applied Cryptography: Protocols, Algorithms, 172 and Source Code in C", 2nd ed., John Wiley & Sons, Inc., 173 1996. 175 [TLS10] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 176 RFC 2246, January 1999. 178 [TLS11] Dierks, T. and E. Rescorla, "The Transport Layer Security 179 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 181 [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security 182 (TLS) Protocol Version 1.2", RFC 5246, July 2008. 184 7.2. Informative References 186 [COPA] Kumar, S., Paar, C., Pelzl, J., Pfeiffer, G., and M. 187 Schimmler, "Breaking Ciphers with COPACOBANA - A Cost- 188 Optimized Parallel Code Breaker", Workshop on Cryptographic 189 Hardware and Embedded Systems (CHES 2006), Yokohama, Japan, 190 October 2006. 192 [DH] Diffie, W. and M. Hellman, "Exhaustive Cryptanalysis of the 193 NBS Data Encryption Standard", IEEE Computer, volume 10, 194 issue 6, June 1977. 196 Author's Address 198 Pasi Eronen (editor) 199 Nokia Research Center 200 P.O. Box 407 201 FIN-00045 Nokia Group 202 Finland 204 Email: pasi.eronen@nokia.com 206 Full Copyright Statement 208 Copyright (C) The IETF Trust (2008). 210 This document is subject to the rights, licenses and restrictions 211 contained in BCP 78, and except as set forth therein, the authors 212 retain all their rights. 214 This document and the information contained herein are provided on an 215 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 216 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 217 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 218 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 219 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 220 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 222 Intellectual Property 224 The IETF takes no position regarding the validity or scope of any 225 Intellectual Property Rights or other rights that might be claimed to 226 pertain to the implementation or use of the technology described in 227 this document or the extent to which any license under such rights 228 might or might not be available; nor does it represent that it has 229 made any independent effort to identify any such rights. Information 230 on the procedures with respect to rights in RFC documents can be 231 found in BCP 78 and BCP 79. 233 Copies of IPR disclosures made to the IETF Secretariat and any 234 assurances of licenses to be made available, or the result of an 235 attempt made to obtain a general license or permission for the use of 236 such proprietary rights by implementers or users of this 237 specification can be obtained from the IETF on-line IPR repository at 238 http://www.ietf.org/ipr. 240 The IETF invites any interested party to bring to its attention any 241 copyrights, patents or patent applications, or other proprietary 242 rights that may cover technology that may be required to implement 243 this standard. Please address the information to the IETF at 244 ietf-ipr@ietf.org.