idnits 2.17.1 draft-ietf-tls-ssl-mods-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 Introduction 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 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 (November 26, 1996) is 10003 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) No issues found here. Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Transport Layer Security Working Group Tim Dierks 2 INTERNET-DRAFT Consensus Development 3 Expires May 31, 1997 November 26, 1996 5 Modifications to the SSL protocol for TLS 6 8 Status of this memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, and 12 its working groups. Note that other groups may also distribute working 13 documents as Internet- Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or made obsolete by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference material 18 or to cite them other than as work in progress. 20 To learn the current status of any Internet-Draft, please check the 21 1id-abstracts.txt listing contained in the Internet Drafts Shadow 22 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 23 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 25 Abstract 27 This document recommends for several modifications be made to the SSL 28 3.0 protocol as it is standardized by the IETF under the name of TLS. 29 These changes primarily standardize various technical details of the 30 protocol and make some other minor modifications. 32 1. MAC algorithm 34 SSL 3.0 uses a version of the HMAC algorithm which is not the most 35 recent or the recommended standard. The SSL MAC is defined as: 37 hash(MAC_secret + pad_2 + 38 hash(MAC_secret + pad_1 + data)); 40 Where data is the concatenation of several record header fields and the 41 record data. pad_1 and pad_2 are repetitions of the value 0x36 and 0x5C, 42 respectively. These bytes are repeated a number of times dependent on 43 which hash algorithm is being used: 48 times for MD5 and 40 times for 44 SHA. 46 I recommend moving to HMAC as described in 47 by incorporating this algorithm into 48 the TLS standard (or by referring to it, should it become an RFC 49 standard). This formulation uses a 64 byte pad which is combined with 50 the MAC secret using XOR rather than concatenation. 52 This would replace the MAC formulations used in the certificate verify 53 and finished messages (where the MAC_secret is the master secret) and 54 the MAC formulation used in the record layer (where the MAC_secret is 55 generated specifically for each connection direction.) 57 2. MAC contents 59 Currently, the SSL record layer applies the MAC to every element in the 60 record except for the protocol version encoded into every packet. It is 61 inappropriate to transmit values which might affect the functionality of 62 the connection without applying the MAC to these values. If the version 63 number does not control the function of the channel, it should be 64 eliminated; if it does affect the communication, it should be MACed. 65 Thus, I recommend that the data which is MAC`d be amended to: 67 seq_num + SSLCompressed.type + SSLCompressed.version + 68 SSLCompressed.length + SSLCompressed.fragment 70 3. Block padding 72 Padding is required when working with block ciphers to expand source 73 data to an even multiple of the block length. SSL specifies padding, but 74 does not specify a particular value. In order to ensure that 75 implementors do not accidentally transmit unintended data in 76 uninitialized padding fields, I recommend that the TLS add a requirement 77 that the padding be initialized to a particular value. I propose that 78 the padding field must be zeroed and that implementations should check 79 for appropriate padding on incoming records. 81 4. Message order standardization 83 In the original SSL 3.0 specification, an error made the statement of 84 when the certificate request message should be transmitted unclear, and 85 different implementations send it in two places: either before or after 86 the server key exchange message. I propose that for the TLS 87 specification, the certificate request message be clearly specified to 88 follow the server key exchange message. 90 5. Certificate chain contents 92 In the original SSL 3.0 specification, the text required that a complete 93 X.509 certificate chain be sent up to and including the self-signed root 94 cert. It is claimed that this was not the intent of the drafters, and in 95 fact, many implementations do not comply with this portion of the 96 standard. Thus, I propose that the TLS specification clearly state that 97 a partial certificate chain is acceptable if it can be reasonably hoped 98 that the peer will hold all needed certificates to complete the chain. 100 6. The no_certificate alert 102 The no_certificate alert, which is to be sent by a client which does not 103 have a suitable certificate to provide a server, presents a subtle 104 problem to the SSL implementer. Because the message order of the SSL 105 protocol is for the most part well defined and enforced, what messages 106 have arrived is very important to the state machine which manages the 107 handshake protocol. Because this alert can replace a handshake message, 108 the alert protocol must communicate to the handshake protocol that this 109 alert has arrived. This is the only place where such a piece of 110 promiscuity is required, thus I recommend that in place of sending a 111 no_certificate alert, TLS clients who do not have a suitable certificate 112 for a server submit instead an Certificate message which contains no 113 certificates. 115 7. Additional alerts 117 SSL doesn`t have a great deal of variety in its error alerts. I propose 118 that the following alerts be added to the specification: 120 internal_error [fatal]: an internal error unrelated to the peer or 121 the correctness of the protocol makes it impossible to continue (such as 122 a memory allocation failure). 123 user_canceled [fatal]: the user aborted this handshake or connection 124 for some reason. 125 decrypt_error [fatal]: a public or private key operation failed due 126 to using the wrong key 127 decode_error [fatal]: a message could not be decoded because some 128 field was out of the specified range or the length of the message was 129 incorrect. 130 export_restriction [fatal]: an attempt to circumvent export 131 restrictions was detected; for example, attemption to transfer a 1024 132 bit ephemeral RSA key for the RSA_EXPORT handshake method. 133 protocol_version [fatal]: the protocol version the peer has 134 attempted to negotiate is recognized, but not supported. (For example, 135 old protocol versions might be avoided for security reasons). 136 record_overflow [fatal]: an SSLCiphertext record was received which 137 had a length more than 2^14+2048 bytes, or a record decrypted to a 138 SSLCompressed record with more than 2^14+1024 bytes. 139 decryption_failed [fatal]: a SSLCiphertext decrypted in an invalid 140 way: either it wasn`t an even multiple of the block length or its 141 padding values, when checked, weren`t correct. 142 access_denied [fatal]: a valid certificate was received, but it did 143 not pass the access control mechanism. 144 unknown_ca [fatal]: a valid certificate chain or partial chain was 145 received, but the certificate was not accepted because the CA 146 certificate could not be located or couldn`t be matched with a known, 147 trusted CA. 148 insufficient_security [fatal]: returned instead of handshake_failure 149 when a negotiation has failed specifically because one of the parties 150 requires ciphers more secure than those supported by their peer. 151 no_renegotiation [warning]: generated in response to a hello request 153 or a client hello sent on an already negotiated channel. This informs 154 the requestor that no response will be generated, as this entity does 155 not want to renegotiate security parameters (as you might wish to do if 156 there` no way to communicate security parameters up the stack to the 157 client after initial negotiation. 159 8. Seperation of Record and Handshake layers 161 The SSL Record Protocol and Handshake Protocol can be viewed as two 162 independant layered protocols: the Record Protocol provides encrypted, 163 reliable transport, and the Handshake Protocol provides algorithm and 164 key negotiation and peer authentication. I propose that they be formally 165 seperated into two documents, or at least two distinct sections of the 166 TLS document. This should make their interoperation clearer, aiding 167 security analysis and perhaps allowing utilization of the Record 168 Protocol with some other handshake protocol or vice-versa. 170 9. Additional Record Protocol clients 172 The SSL Record Protocol supports transmitting many different kinds of 173 records over a single connection. This is already used for 174 distinguishing different kinds of protocol messages from each other and 175 from application data. I propose that TLS clearly specify that layered 176 protocols are allowed to use the Record Protocol to transport new record 177 types.