6. The TLS Record Protocol

   The TLS Record Protocol is a layered protocol. At each layer,
   messages may include fields for length, description, and content.
   The Record Protocol takes messages to be transmitted, fragments the
   data into manageable blocks, optionally compresses the data, applies
   a MAC, encrypts, and transmits the result. Received data is
   decrypted, verified, decompressed, and reassembled, then delivered to
   higher level clients.

   Four record protocol clients are described in this document: the
   handshake protocol, the alert protocol, the change cipher spec
   protocol, and the application data protocol. In order to allow
   extension of the TLS protocol, additional record types can be
   supported by the record protocol. Any new record types should
   allocate type values immediately beyond the ContentType values for
   the four record types described here (see Appendix A.2). If a TLS
   implementation receives a record type it does not understand, it
   should just ignore it. Any protocol designed for use over TLS must be
   carefully designed to deal with all possible attacks against it.
   Note that because the type and length of a record are not protected
   by encryption, care should be take to minimize the value of traffic
   analysis of these values.







 
RFC 2246              The TLS Protocol Version 1.0          January 1999


6.1. Connection states

   A TLS connection state is the operating environment of the TLS Record
   Protocol. It specifies a compression algorithm, encryption algorithm,
   and MAC algorithm. In addition, the parameters for these algorithms
   are known: the MAC secret and the bulk encryption keys and IVs for
   the connection in both the read and the write directions. Logically,
   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 can be set by the TLS Handshake
   Protocol, and the Handshake Protocol can selectively make 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. It is illegal to make
   a state which has not been initialized with security parameters a
   current state. The initial current state always specifies that no
   encryption, compression, or MAC will be used.

   The security parameters for a TLS Connection read and write state are
   set by providing the following values:

   connection end
       Whether this entity is considered the "client" or the "server" in
       this connection.

   bulk encryption algorithm
       An algorithm to be used for bulk encryption. This specification
       includes the key size of this algorithm, how much of that key is
       secret, whether it is a block or stream cipher, the block size of
       the cipher (if appropriate), and whether it is considered an
       "export" cipher.

   MAC algorithm
       An algorithm to be used for message authentication. This
       specification includes the size of the hash which is returned by
       the MAC algorithm.

   compression algorithm
       An algorithm to be used for data compression. This specification
       must include all information the algorithm requires to do
       compression.

   master secret
       A 48 byte secret shared between the two peers in the connection.

   client random
       A 32 byte value provided by the client.




 
RFC 2246              The TLS Protocol Version 1.0          January 1999


   server random
       A 32 byte value provided by the server.

   These parameters are defined in the presentation language as:

       enum { server, client } ConnectionEnd;

       enum { null, rc4, rc2, des, 3des, des40 } BulkCipherAlgorithm;

       enum { stream, block } CipherType;