doc/protocol/draft-ietf-tls-ssl-mods-00.txt

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