15.3 TLS PROTOCOL

Team-Fly

Early in 1996, the IETF chartered a TLS WG within the security and transport areas. The objective of the IETF TLS WG was to write Internet standards track RFCs for a TLS protocol using the currently available specifications of SSL (2.0 and 3.0), PCT (1.0), and the secure shell (SSH) version 2 as a basis.^[10] Shortly before the IETF meeting in December 1996, a first TLS 1.0 document was released as an Internet-Draft. The document was essentially the same as the SSL 3.0 specification. In fact, it was the explicit strategy of the IETF TLS WG to have the TLS 1.0 specification be based on SSL 3.0, as opposed to SSL 2.0, PCT 1.0, SSH version 2, or any other transport layer security protocol proposal. At least three major modifications were suggested for SSL 3.0 to be incorporated into TLS 1.0:

The HMAC construction developed in the IETF IPsec WG should be adopted and consistently used in TLS 1.0.
The FORTEZZA token-based KEA should be removed from TLS 1.0, since it refers to a proprietary and unpublished technology. Instead, a DSS-based key exchange mechanism should be included in TLS 1.0.
The TLS Record Protocol and the TLS Handshake Protocol should be separated out and specified more clearly in related documents.

After having adopted these modifications, the resulting TLS protocol was specified in a series of Internet-Drafts. In January 1999, the TLS protocol version 1.0 was specified in RFC 2246 [16] and submitted to the Internet standards track (as a Proposed Standard). The differences between TLS 1.0 and SSL 3.0 are not huge, but they are significant enough that TLS 1.0 and SSL 3.0 do not easily interoperate. Nevertheless, TLS 1.0 does incorporate a mechanism by which a TLS implementation can back down to SSL 3.0.

Similar to the SSL protocol, the TLS protocol is a layered protocol that consists of a TLS Record Protocol and several TLS subprotocols layered on top of it:

On the lower layer, the TLS Record Protocol takes messages to be transmitted, fragments them into manageable data blocks (so-called "TLS records"), optionally compresses them, computes and appends a MAC to each record, encrypts the result, and transmits it. Again, similar to SSL, the resulting records are called TLSPlaintext, TLSCompressed, and TLSCiphertext. A received TLSCiphertext record, in turn, is decrypted, verified, decompressed, and reassembled before it is delivered to the appropriate application protocol. A TLS connection state is the operating environment of the TLS Record Protocol. It specifies compression, encryption, and message authentication algorithms, and determines parameters for these algorithms, such as encryption and MAC keys and IVs for a connection in both the read and write directions. There are always four connection states outstanding: the current read and write states and the pending read and write states. All records are processed under the current read and write states. The security parameters for the pending states are set by the TLS Handshake Protocol, and the handshake protocol selectively makes either of the pending states current, in which case the appropriate current state is disposed of and replaced with the pending state; the pending state is then reinitialized to an empty state.
On the higher layer, there are several TLS subprotocols layered on top of the TLS Record Protocol. For example, the TLS Handshake Protocol is used to negotiate session and connection information elements that comprise a session identifier, a peer certificate, a compression method, a cipher spec, a master key, and a flag whether the session is resumable and can be used to initiate new connections. These items are used to create security parameters for use by the TLS Record Protocol when protecting application data. In addition, there are a TLS Change Cipher Spec Protocol and a TLS Alert Protocol. Both are similar to the corresponding SSL protocols (and are not further addressed in this book).

After a TLS handshake has been performed, the client and server can exchange application data messages. These messages are carried by the TLS Record Protocol and fragmented, compressed, authenticated, and encrypted accordingly. The messages are treated as transparent data to the TLS record layer.

The cipher suites that are specified for TLS 1.0 are summarized in Table 15.4. The key exchange and encryption mechanisms, as well as the one-way hash function that are used in a particular cipher suite, are all encoded in its name. For example, the cipher suite TLS_RSA_WITH_RC4_128_MD5 uses RSA public key encryption for key exchange, RC4 with 128 bit session keys for encryption, and MD5 for computing one-way hash function results. Similarly, the cipher suite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA uses the Diffie-Hellman key exchange algorithm (DH) for key exchange, the digital signature standard (DSS) to compute and verify digital signatures, Tripe-DES in CBC mode for encryption, and SHA-1 for computing one-way hash function results. Consequently, a TLS cipher suite is always named TLS_X_WITH_Y_Z, where X refers to the key exchange algorithm, Y to the encryption algorithm, and Z to the one-way hash function that is being used. The key exchange and encryption algorithms, as well as the one-way hash functions that are specified in TLS 1.0, are itemized and further explained in Tables 15.5 to 15.7. Note that Tables 15.4 and 15.6 also indicate whether a particular implementation of a cipher suite or encryption algorithm is exportable from the United States. In Table 15.6, the type of a cipher indicates whether it is a stream cipher or a block cipher running in CBC mode. Similarly, the key length indicates the number of bytes that are used for generating the encryption keys, whereas the expanded key length indicates the number of bytes actually fed into the encryption algorithm. Finally, the effective key bits measure how much entropy is in the key material being fed into the encryption routine, and the IV size measures how much data needs to be generated for the IV.

TLS 1.0 as specified in RFC 2246 [16] was submitted to the IESG for consideration as a Proposed Standard for the Internet in January 1999. Meanwhile, two other standards track RFC documents and have been officially released by the IETF TLS WG:

RFC 2712 specifies the addition of Kerberos Cipher Suites to TLS [17].
RFC 2817 specifies how to upgrade to TLS Within HTTP/1.1 [18].

In addition, an informational RFC document specifies the use of HTTP over TLS (i.e., HTTPS) [19]. Finally, there are various Internet-Drafts specifying specific issues related to TLS or the use of TLS to secure TCP-based application protocols. Refer to the home page of the IETF TLS WG for an overview about the most recent developments and achievements.

^[10]Note that at this point in time the SSH protocol had been investigated by the IETF TLS WG, and that the IETF later chartered a SECSH WG to update and standardize the SSH protocol independently of the TLS protocol. The SSH protocol is overviewed and discussed in Chapter 16.

Team-Fly