idnits 2.17.1 draft-ietf-tls-56-bit-ciphersuites-00.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == 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 3 pages 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 (April 13, 1999) is 9144 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 113, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'TLS' Summary: 7 errors (**), 0 flaws (~~), 3 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 Richard Harrington 4 Expires October, 1999 Microsoft Corporation 5 April 13, 1999 7 56-bit Export Cipher Suites For TLS 8 draft-ietf-tls-56-bit-ciphersuites-00.txt 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with 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 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 2. Introduction 34 This document describes several new cipher suites to be used with 35 the Transport Layer Security (TLS) protocol. Recent changes in 36 US export regulations permit the export of software programs using 37 56-bit data encryption and 1024-bit key exchange. The cipher 38 suites described in this document take full advantage of these new 39 regulations. 41 3. The CipherSuites 43 The following values define the CipherSuite codes used in the client 44 hello and server hello messages. 46 The following CipherSuite definitions require that the server 47 provide an RSA certificate that can be used for key exchange. The 48 server may request either an RSA or a DSS signature-capable 49 certificate in the certificate request message. 51 CipherSuite TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA = { 0x00,0x62 }; 52 CipherSuite TLS_RSA_EXPORT1024_WITH_RC4_56_SHA = { 0x00,0x64 }; 53 The following CipherSuite definitions are used for 54 server-authenticated (and optionally client-authenticated) 55 Diffie-Hellman. DHE denotes ephemeral Diffie-Hellman, where the 56 Diffie-Hellman parameters are signed by a DSS certificate, which 57 has been signed by the CA. 59 CipherSuite TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA = { 0x00,0x63 }; 60 CipherSuite TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA = { 0x00,0x65 }; 61 CipherSuite TLS_DHE_DSS_WITH_RC4_128_SHA = { 0x00,0x66 }; 63 4. CipherSuite definitions 65 CipherSuite Is Key Cipher Hash 66 Exportable Exchange 68 TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA * RSA_EXPORT1024 DES_CBC SHA 69 TLS_RSA_EXPORT1024_WITH_RC4_56_SHA * RSA_EXPORT1024 RC4_56 SHA 70 TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA * DHE_DSS_EXPORT1024 DES_CBC SHA 71 TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA * DHE_DSS_EXPORT1024 RC4_56 SHA 72 TLS_DHE_DSS_WITH_RC4_128_SHA DHE_DSS RC4_128 SHA 74 * Indicates IsExportable is True 76 Key 77 Exchange 78 Algorithm Description Key size limit 80 RSA_EXPORT1024 RSA key exchange RSA = 1024 bits 81 DHE_DSS_EXPORT1024 Ephemeral DH with DSS signatures DH = 1024 bits 83 Key size limit 84 The key size limit gives the size of the largest public key that 85 can be legally used for encryption in cipher suites that are 86 exportable. 88 Key Expanded Effective IV Block 89 Cipher Type Material Key Material Key Bits Size Size 91 RC4_56 Stream 7 16 56 0 N/A 92 DES_CBC Block 8 8 56 8 8 94 5. Implementation Notes 96 When an RSA_EXPORT1024 cipher suite is used, and the server's RSA 97 Key is larger than 1024 bits in length, then the server must send 98 a server key exchange message to the client. This message is to 99 contain a temporary RSA key, signed by the server. This temporary 100 RSA key should be the maximum allowable length (i.e., 1024 bits). 102 Servers with a large RSA key will often maintain two temporary RSA 103 keys: a 512-bit key used to support the RSA_EXPORT cipher suites, 104 and a 1024-bit key used to support the RSA_EXPORT1024 cipher suites. 106 When 56-bit DES keys are derived for an export cipher suite, the 107 additional export key derivation step must be performed. That is, 108 the final read and write DES keys (and the IV) are not taken 109 directly from the key_block. 111 6. References 113 [TLS] T. Dierks, C. Allen, The TLS Protocol, 114 , November 1998. 116 7. Authors 118 John Banes Richard Harrington 119 Microsoft Corp. Microsoft Corp. 120 jbanes@microsoft.com richha@microsoft.com