idnits 2.17.1 draft-ietf-tls-56-bit-ciphersuites-01.txt: 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 Internet-Drafts being working documents. ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 4 characters in excess of 72. 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 (July 19, 2001) is 8310 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) == Unused Reference: 'TLS' is defined on line 111, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'TLS' Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Layer Security Working Group John Banes 3 INTERNET-DRAFT Microsoft Corporation 4 Expires January, 2002 Richard Harrington 5 Qpass Incorporated 6 July 19, 2001 8 56-bit Export Cipher Suites For TLS 9 draft-ietf-tls-56-bit-ciphersuites-01.txt 11 1. Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. Internet-Drafts are working documents of 15 the Internet Engineering Task Force (IETF), its areas, and its 16 working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or made obsolete by other documents at 21 any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 2. Introduction 32 This document describes several cipher suites to be used with the 33 Transport Layer Security (TLS) protocol. Changes in US export 34 regulations in 1999 permitted the export of software programs 35 using 56-bit data encryption and 1024-bit key exchange. 36 The cipher suites described in this document were designed to take 37 advantage of this change in the regulations. 39 3. The CipherSuites 41 The following values define the CipherSuite codes used in the client 42 hello and server hello messages. 44 The following CipherSuite definitions require that the server 45 provide an RSA certificate that can be used for key exchange. The 46 server may request either an RSA or a DSS signature-capable 47 certificate in the certificate request message. 49 CipherSuite TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA = { 0x00,0x62 }; 50 CipherSuite TLS_RSA_EXPORT1024_WITH_RC4_56_SHA = { 0x00,0x64 }; 51 The following CipherSuite definitions are used for 52 server-authenticated (and optionally client-authenticated) 53 Diffie-Hellman. DHE denotes ephemeral Diffie-Hellman, where the 54 Diffie-Hellman parameters are signed by a DSS certificate, which 55 has been signed by the CA. 57 CipherSuite TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA = { 0x00,0x63 }; 58 CipherSuite TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA = { 0x00,0x65 }; 59 CipherSuite TLS_DHE_DSS_WITH_RC4_128_SHA = { 0x00,0x66 }; 61 4. CipherSuite definitions 63 CipherSuite Is Key Cipher Hash 64 Exportable Exchange 66 TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA * RSA_EXPORT1024 DES_CBC SHA 67 TLS_RSA_EXPORT1024_WITH_RC4_56_SHA * RSA_EXPORT1024 RC4_56 SHA 68 TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA * RSA_EXPORT1024 DES_CBC SHA 69 TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA * DHE_DSS_EXPORT1024 RC4_56 SHA 70 TLS_DHE_DSS_WITH_RC4_128_SHA DHE_DSS RC4_128 SHA 72 * Indicates IsExportable is True 74 Key 75 Exchange 76 Algorithm Description Key size limit 78 RSA_EXPORT1024 RSA key exchange RSA = 1024 bits 79 DHE_DSS_EXPORT1024 Ephemeral DH with DSS signatures DH = 1024 bits 81 Key size limit 82 The key size limit gives the size of the largest public key that 83 can be legally used for encryption in cipher suites that are 84 exportable. 86 Key Expanded Effective IV Block 87 Cipher Type Material Key Material Key Bits Size Size 89 RC4_56 Stream 7 16 56 0 N/A 90 DES_CBC Block 8 8 56 8 8 92 5. Implementation Notes 94 When an RSA_EXPORT1024 cipher suite is used, and the server's RSA 95 Key is larger than 1024 bits in length, then the server must send 96 a server key exchange message to the client. This message is to 97 contain a temporary RSA key, signed by the server. This temporary 98 RSA key should be the maximum allowable length (i.e., 1024 bits). 100 Servers with a large RSA key will often maintain two temporary RSA 101 keys: a 512-bit key used to support the RSA_EXPORT cipher suites, 102 and a 1024-bit key used to support the RSA_EXPORT1024 cipher suites. 104 When 56-bit DES keys are derived for an export cipher suite, the 105 additional export key derivation step must be performed. That is, 106 the final read and write DES keys (and the IV) are not taken 107 directly from the key_block. 109 6. References 111 [TLS] T. Dierks, C. Allen, The TLS Protocol, 112 , November 1998. 114 7. Authors 116 John Banes Richard Harrington 117 Microsoft Corp. Qpass Inc. 118 jbanes@microsoft.com rharrington@qpass.com