draft-ietf-tls-des-idea-02.txt   rfc5469.txt 
TLS Working Group P. Eronen, Ed. Network Working Group P. Eronen, Ed.
Internet-Draft Nokia Request for Comments: 5469 Nokia
Intended status: Informational June 25, 2008 Category: Informational February 2009
Expires: December 27, 2008
DES and IDEA Cipher Suites for Transport Layer Security (TLS) DES and IDEA Cipher Suites for Transport Layer Security (TLS)
draft-ietf-tls-des-idea-02.txt
Status of this Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This memo provides information for the Internet community. It does
and may be updated, replaced, or obsoleted by other documents at any not specify an Internet standard of any kind. Distribution of this
time. It is inappropriate to use Internet-Drafts as reference memo is unlimited.
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (c) 2009 IETF Trust and the persons identified as the
http://www.ietf.org/shadow.html. document authors. All rights reserved.
This Internet-Draft will expire on December 27, 2008. This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://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.
Abstract Abstract
TLS specification versions 1.0 (RFC 2246) and 1.1 (RFC 4346) included Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC
cipher suites based on DES (Data Encryption Standard) and IDEA 4346) include cipher suites based on DES (Data Encryption Standard)
(International Data Encryption Algorithm) algorithms. DES (when used and IDEA (International Data Encryption Algorithm) algorithms. DES
in single-DES mode) and IDEA are no longer recommended for general (when used in single-DES mode) and IDEA are no longer recommended for
use in TLS, and have been removed from TLS 1.2 main specification general use in TLS, and have been removed from TLS version 1.2 (RFC
(RFC 5246). This document specifies these cipher suites for 5246). This document specifies these cipher suites for completeness
completeness, and discusses reasons why their use is no longer and discusses reasons why their use is no longer recommended.
recommended.
1. Introduction 1. Introduction
TLS specification versions 1.0 [TLS10] and 1.1 [TLS11] included TLS versions 1.0 [TLS10] and 1.1 [TLS11] include cipher suites based
cipher suites based on DES (Data Encryption Standard) and IDEA on DES (Data Encryption Standard) and IDEA (International Data
(International Data Encryption Algorithm) algorithms. DES (when used Encryption Algorithm) algorithms. DES (when used in single-DES mode)
in single-DES mode) and IDEA are no longer recommended for general and IDEA are no longer recommended for general use in TLS, and have
use in TLS, and have been removed from TLS 1.2 main specification been removed from TLS version 1.2 [TLS12].
[TLS12].
This document specifies these cipher suites for completeness, and This document specifies these cipher suites for completeness and
discusses reasons why their use is no longer recommended. discusses reasons why their use is no longer recommended.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [REQ]. document are to be interpreted as described in [REQ].
2. DES Cipher Suites 2. DES Cipher Suites
DES (Data Encryption Standard) is a block cipher which was originally DES (Data Encryption Standard) is a block cipher that was originally
approved as US federal standard in 1976, and is specified in [DES]. approved as a US federal standard in 1976, and is specified in [DES].
For TLS key generation purposes, DES is treated as having a 64-bit For TLS key generation purposes, DES is treated as having a 64-bit
key, but it still provides only 56 bits of protection, as 8 of the 64 key, but it still provides only 56 bits of protection, as 8 of the 64
bits are not used by the algorithm. DES uses a 64-bit block size. bits are not used by the algorithm. DES uses a 64-bit block size.
The following cipher suites have been defined for using DES in CBC The following cipher suites have been defined for using DES in Cipher
mode in TLS: Block Chaining (CBC) mode in TLS:
CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 };
CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C }; CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C };
CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F }; CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F };
CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 }; CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 };
CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }; CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 };
CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
The key exchange algorithms (RSA, DH_DSS, DH_RSA, DHE_DSS, DHE_RSA, The key exchange algorithms (RSA, DH_DSS, DH_RSA, DHE_DSS, DHE_RSA,
and DH_anon) and the MAC algorithm (SHA) are defined in the base TLS and DH_anon) and the MAC (Message Authentication Code) algorithm
specification. (SHA) are defined in the base TLS specification.
3. IDEA Cipher Suite 3. IDEA Cipher Suite
IDEA (International Data Encryption Algorithm) is a block cipher IDEA (International Data Encryption Algorithm) is a block cipher
designed by Xuejia Lai and James Massey [IDEA] [SCH]. IDEA uses a designed by Xuejia Lai and James Massey [IDEA] [SCH]. IDEA uses a
128-bit key and operates on 64-bit blocks. 128-bit key and operates on 64-bit blocks.
The following cipher suite has been defined for using IDEA in CBC The following cipher suite has been defined for using IDEA in CBC
mode in TLS: mode in TLS:
CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 };
The key exchange algorithm (RSA) and the MAC algorithm (SHA) are The key exchange algorithm (RSA) and the MAC algorithm (SHA) are
defined in the base TLS specification. defined in the base TLS specification.
4. Security Considerations 4. Security Considerations
4.1. DES Cipher Suites 4.1. DES Cipher Suites
DES has an effective key strength of 56 bits, which has been been DES has an effective key strength of 56 bits, which has been known to
known to be vulnerable to practical brute force attacks for over 20 be vulnerable to practical brute force attacks for over 20 years
years [DH]. A relatively recent 2006 paper by Kumar et al. [COPA] [DH]. A relatively recent 2006 paper by Kumar, et al. [COPA]
describes a system which performs exhaustive key search in less than describes a system that performs an exhaustive key search in less
nine days on average, and costs less than 10,000 USD to build. than nine days on average, and costs less than 10,000 USD to build.
Given this, the single-DES cipher suites SHOULD NOT be implemented by Given this, the single-DES cipher suites SHOULD NOT be implemented by
TLS libraries. If a TLS library implements these cipher suites, it TLS libraries. If a TLS library implements these cipher suites, it
SHOULD NOT enable them by default. Experience has also shown that SHOULD NOT enable them by default. Experience has also shown that
rarely used code is a source of security and interoperability rarely used code is a source of security and interoperability
problems, so existing implementations SHOULD consider removing these problems, so existing implementations SHOULD consider removing these
cipher suites. cipher suites.
4.2. IDEA Cipher Suite 4.2. IDEA Cipher Suite
IDEA has a 128-bit key, and thus is not vulnerable to exhaustive key IDEA has a 128-bit key, and thus is not vulnerable to an exhaustive
search. However, the IDEA cipher suite for TLS has not seen key search. However, the IDEA cipher suite for TLS has not seen
widespread use: most implementations either do not support it, do not widespread use: most implementations either do not support it, do not
enable it by default, or do not negotiate it when other algorithms enable it by default, or do not negotiate it when other algorithms
(such as AES, 3DES, or RC4) are available. (such as AES, 3DES, or RC4) are available.
Experience has shown that rarely used code is a source of security Experience has shown that rarely used code is a source of security
and interoperability problems; given this, the IDEA cipher suite and interoperability problems; given this, the IDEA cipher suite
SHOULD NOT be implemented by TLS libraries, and SHOULD be removed SHOULD NOT be implemented by TLS libraries and SHOULD be removed from
from existing implementations. existing implementations.
5. IANA Considerations 5. IANA Considerations
IANA has already allocated values for the cipher suites described in IANA has already allocated values for the cipher suites described in
this document in the TLS Cipher Suite Registry, defined in [TLS11]. this document in the TLS Cipher Suite Registry, defined in [TLS11].
IANA is requested to update (has updated) the references of these IANA has updated the references of these cipher suites to point to
cipher suites to point to this document: this document:
Value Description Reference Value Description Reference
----------- -------------------------------------- --------- ----------- -------------------------------------- ---------
0x00,0x07 TLS_RSA_WITH_IDEA_CBC_SHA [RFCnnnn] 0x00,0x07 TLS_RSA_WITH_IDEA_CBC_SHA [RFC5469]
0x00,0x09 TLS_RSA_WITH_DES_CBC_SHA [RFCnnnn] 0x00,0x09 TLS_RSA_WITH_DES_CBC_SHA [RFC5469]
0x00,0x0C TLS_DH_DSS_WITH_DES_CBC_SHA [RFCnnnn] 0x00,0x0C TLS_DH_DSS_WITH_DES_CBC_SHA [RFC5469]
0x00,0x0F TLS_DH_RSA_WITH_DES_CBC_SHA [RFCnnnn] 0x00,0x0F TLS_DH_RSA_WITH_DES_CBC_SHA [RFC5469]
0x00,0x12 TLS_DHE_DSS_WITH_DES_CBC_SHA [RFCnnnn] 0x00,0x12 TLS_DHE_DSS_WITH_DES_CBC_SHA [RFC5469]
0x00,0x15 TLS_DHE_RSA_WITH_DES_CBC_SHA [RFCnnnn] 0x00,0x15 TLS_DHE_RSA_WITH_DES_CBC_SHA [RFC5469]
0x00,0x1A TLS_DH_anon_WITH_DES_CBC_SHA [RFCnnnn] 0x00,0x1A TLS_DH_anon_WITH_DES_CBC_SHA [RFC5469]
This document does not create any new registries to be maintained by This document does not create any new registries to be maintained by
IANA, and does not require any new assignments from existing IANA, and does not require any new assignments from existing
registries. registries.
6. Acknowledgments 6. Acknowledgments
The editor would like to thank Steven Bellovin, Uri Blumenthal, The editor would like to thank Steven Bellovin, Uri Blumenthal,
Michael D'Errico, Paul Hoffman, Simon Josefsson, Bodo Moeller, Tom Michael D'Errico, Paul Hoffman, Simon Josefsson, Bodo Moeller, Tom
Petch, Martin Rex, and Len Sassaman for their contributions to Petch, Martin Rex, and Len Sassaman for their contributions to
skipping to change at page 5, line 4 skipping to change at page 4, line 30
and Source Code in C", 2nd ed., John Wiley & Sons, Inc., and Source Code in C", 2nd ed., John Wiley & Sons, Inc.,
1996. 1996.
[TLS10] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [TLS10] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[TLS11] Dierks, T. and E. Rescorla, "The Transport Layer Security [TLS11] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, July 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
7.2. Informative References 7.2. Informative References
[COPA] Kumar, S., Paar, C., Pelzl, J., Pfeiffer, G., and M. [COPA] Kumar, S., Paar, C., Pelzl, J., Pfeiffer, G., and M.
Schimmler, "Breaking Ciphers with COPACOBANA - A Cost- Schimmler, "Breaking Ciphers with COPACOBANA - A Cost-
Optimized Parallel Code Breaker", Workshop on Cryptographic Optimized Parallel Code Breaker", Workshop on Cryptographic
Hardware and Embedded Systems (CHES 2006), Yokohama, Japan, Hardware and Embedded Systems (CHES 2006), Yokohama, Japan,
October 2006. October 2006.
[DH] Diffie, W. and M. Hellman, "Exhaustive Cryptanalysis of the [DH] Diffie, W. and M. Hellman, "Exhaustive Cryptanalysis of the
NBS Data Encryption Standard", IEEE Computer, volume 10, NBS Data Encryption Standard", IEEE Computer, Volume 10,
issue 6, June 1977. Issue 6, June 1977.
Author's Address Author's Address
Pasi Eronen (editor) Pasi Eronen (editor)
Nokia Research Center Nokia Research Center
P.O. Box 407 P.O. Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
Email: pasi.eronen@nokia.com EMail: pasi.eronen@nokia.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 21 change blocks. 
67 lines changed or deleted 55 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/