Network Working Group T. Dierks
`Request for Comments: 2246 Certicom
`Category: Standards Track C. Allen
` Certicom
` January 1999
`
` The TLS Protocol
` Version 1.0
`
`Status of this Memo
`
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (1999). All Rights Reserved.
`
`Abstract
`
` This document specifies Version 1.0 of the Transport Layer Security
` (TLS) protocol. The TLS protocol provides communications privacy over
` the Internet. The protocol allows client/server applications to
` communicate in a way that is designed to prevent eavesdropping,
` tampering, or message forgery.
`
`Table of Contents
`
` 1. Introduction 3
` 2. Goals 4
` 3. Goals of this document 5
` 4. Presentation language 5
` 4.1. Basic block size 6
` 4.2. Miscellaneous 6
` 4.3. Vectors 6
` 4.4. Numbers 7
` 4.5. Enumerateds 7
` 4.6. Constructed types 8
` 4.6.1. Variants 9
` 4.7. Cryptographic attributes 10
` 4.8. Constants 11
` 5. HMAC and the pseudorandom function 11
` 6. The TLS Record Protocol 13
` 6.1. Connection states 14
`
`Dierks & Allen Standards Track [Page 1]
`
`Petitioner Apple Inc. - Exhibit 1052, p. 1
`
`

`
`RFC 2246 The TLS Protocol Version 1.0 January 1999
`
` 6.2. Record layer 16
` 6.2.1. Fragmentation 16
` 6.2.2. Record compression and decompression 17
` 6.2.3. Record payload protection 18
` 6.2.3.1. Null or standard stream cipher 19
` 6.2.3.2. CBC block cipher 19
` 6.3. Key calculation 21
` 6.3.1. Export key generation example 22
` 7. The TLS Handshake Protocol 23
` 7.1. Change cipher spec protocol 24
` 7.2. Alert protocol 24
` 7.2.1. Closure alerts 25
` 7.2.2. Error alerts 26
` 7.3. Handshake Protocol overview 29
` 7.4. Handshake protocol 32
` 7.4.1. Hello messages 33
` 7.4.1.1. Hello request 33
` 7.4.1.2. Client hello 34
` 7.4.1.3. Server hello 36
` 7.4.2. Server certificate 37
` 7.4.3. Server key exchange message 39
` 7.4.4. Certificate request 41
` 7.4.5. Server hello done 42
` 7.4.6. Client certificate 43
` 7.4.7. Client key exchange message 43
` 7.4.7.1. RSA encrypted premaster secret message 44
` 7.4.7.2. Client Diffie-Hellman public value 45
` 7.4.8. Certificate verify 45
` 7.4.9. Finished 46
` 8. Cryptographic computations 47
` 8.1. Computing the master secret 47
` 8.1.1. RSA 48
` 8.1.2. Diffie-Hellman 48
` 9. Mandatory Cipher Suites 48
` 10. Application data protocol 48
` A. Protocol constant values 49
` A.1. Record layer 49
` A.2. Change cipher specs message 50
` A.3. Alert messages 50
` A.4. Handshake protocol 51
` A.4.1. Hello messages 51
` A.4.2. Server authentication and key exchange messages 52
` A.4.3. Client authentication and key exchange messages 53
` A.4.4. Handshake finalization message 54
` A.5. The CipherSuite 54
` A.6. The Security Parameters 56
` B. Glossary 57
` C. CipherSuite definitions 61
`
`Dierks & Allen Standards Track [Page 2]
`
`Petitioner Apple Inc. - Exhibit 1052, p. 2
`
`

`
`RFC 2246 The TLS Protocol Version 1.0 January 1999
`
` D. Implementation Notes 64
` D.1. Temporary RSA keys 64
` D.2. Random Number Generation and Seeding 64
` D.3. Certificates and authentication 65
` D.4. CipherSuites 65
` E. Backward Compatibility With SSL 66
` E.1. Version 2 client hello 67
` E.2. Avoiding man-in-the-middle version rollback 68
` F. Security analysis 69
` F.1. Handshake protocol 69
` F.1.1. Authentication and key exchange 69
` F.1.1.1. Anonymous key exchange 69
` F.1.1.2. RSA key exchange and authentication 70
` F.1.1.3. Diffie-Hellman key exchange with authentication 71
` F.1.2. Version rollback attacks 71
` F.1.3. Detecting attacks against the handshake protocol 72
` F.1.4. Resuming sessions 72
` F.1.5. MD5 and SHA 72
` F.2. Protecting application data 72
` F.3. Final notes 73
` G. Patent Statement 74
` Security Considerations 75
` References 75
` Credits 77
` Comments 78
` Full Copyright Statement 80
`
`1. Introduction
`
` The primary goal of the TLS Protocol is to provide privacy and data
` integrity between two communicating applications. The protocol is
` composed of two layers: the TLS Record Protocol and the TLS Handshake
` Protocol. At the lowest level, layered on top of some reliable
` transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
` TLS Record Protocol provides connection security that has two basic
` properties:
`
` - The connection is private. Symmetric cryptography is used for
` data encryption (e.g., DES [DES], RC4 [RC4], etc.) The keys for
` this symmetric encryption are generated uniquely for each
` connection and are based on a secret negotiated by another
` protocol (such as the TLS Handshake Protocol). The Record
` Protocol can also be used without encryption.
`
` - The connection is reliable. Message transport includes a message
` integrity check using a keyed MAC. Secure hash functions (e.g.,
` SHA, MD5, etc.) are used for MAC computations. The Record
` Protocol can operate without a MAC, but is generally only used in
`
`Dierks & Allen Standards Track [Page 3]
`
`Petitioner Apple Inc. - Exhibit 1052, p. 3
`
`

`
`RFC 2246 The TLS Protocol Version 1.0 January 1999
`
` this mode while another protocol is using the Record Protocol as
` a transport for negotiating security parameters.
`
` The TLS Record Protocol is used for encapsulation of various higher
` level protocols. One such encapsulated protocol, the TLS Handshake
` Protocol, allows the server and client to authenticate each other and
` to negotiate an encryption algorithm and cryptographic keys before
` the application protocol transmits or receives its first byte of
` data. The TLS Handshake Protocol provides connection security that
` has three basic properties:
`
` - The peer’s identity can be authenticated using asymmetric, or
` public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
` authentication can be made optional, but is generally required
` for at least one of the peers.
`
` - The negotiation of a shared secret is secure: the negotiated
` secret is unavailable to eavesdroppers, and for any authenticated
` connection the secret cannot be obtained, even by an attacker who
` can place himself in the middle of the connection.
`
` - The negotiation is reliable: no attacker can modify the
` negotiation communication without being detected by the parties
` to the communication.
`
` One advantage of TLS is that it is application protocol independent.
` Higher level protocols can layer on top of the TLS Protocol
` transparently. The TLS standard, however, does not specify how
` protocols add security with TLS; the decisions on how to initiate TLS
` handshaking and how to interpret the authentication certificates
` exchanged are left up to the judgment of the designers and
` implementors of protocols which run on top of TLS.
`
`2. Goals
`
` The goals of TLS Protocol, in order of their priority, are:
`
` 1. Cryptographic security: TLS should be used to establish a secure
` connection between two parties.
`
` 2. Interoperability: Independent programmers should be able to
` develop applications utilizing TLS that will then be able to
` successfully exchange cryptographic parameters without knowledge
` of one another’s code.
`
` 3. Extensibility: TLS seeks to provide a framework into which new
` public key and bulk encryption methods can be incorporated as
` necessary. This will also accomplish two sub-goals: to prevent
`
`Dierks & Allen Standards Track [Page 4]
`
`Petitioner Apple Inc. - Exhibit 1052, p. 4
`
`

`
`RFC 2246 The TLS Protocol Version 1.0 January 1999
`
` the need to create a new protocol (and risking the introduction
` of possible new weaknesses) and to avoid the need to implement an
` entire new security library.
`
` 4. Relative efficiency: Cryptographic operations tend to be highly
` CPU intensive, particularly public key operations. For this
` reason, the TLS protocol has incorporated an optional session
` caching scheme to reduce the number of connections that need to
` be established from scratch. Additionally, care has been taken to
` reduce network activity.
`
`3. Goals of this document
`
` This document and the TLS protocol itself are based on the SSL 3.0
` Protocol Specification as published by Netscape. The differences
` between this protocol and SSL 3.0 are not dramatic, but they are
` significant enough that TLS 1.0 and SSL 3.0 do not interoperate
` (although TLS 1.0 does incorporate a mechanism by which a TLS
` implementation can back down to SSL 3.0). This document is intended
` primarily for readers who will be implementing the protocol and those
` doing cryptographic analysis of it. The specification has been
` written with this in mind, and it is intended to reflect the needs of
` those two groups. For that reason, many of the algorithm-dependent
` data structures and rules are included in the body of the text (as
` opposed to in an appendix), providing easier access to them.
`
` This document is not intended to supply any details of service
` definition nor interface definition, although it does cover select
` areas of policy as they are required for the maintenance of solid
` security.
`
`4. Presentation language
`
` This document deals with the formatting of data in an external
` representation. The following very basic and somewhat casually
` defined presentation syntax will be used. The syntax draws from
` several sources in its structure. Although it resembles the
` programming language "C" in its syntax and XDR [XDR] in both its
` syntax and intent, it would be risky to draw too many parallels. The
` purpose of this presentation language is to document TLS only, not to
` have general application beyond that particular goal.
`
`Dierks & Allen Standards Track [Page 5]
`
`Petitioner Apple Inc. - Exhibit 1052, p. 5
`
`

`
`RFC 2246 The TLS Protocol Version 1.0 January 1999
`
`4.1. Basic block size
`
` The representation of all data items is explicitly specified. The
` basic data block size is one byte (i.e. 8 bits). Multiple byte data
` items are concatenations of bytes, from left to right, from top to
` bottom. From the bytestream a multi-byte item (a numeric in the
` example) is formed (using C notation) by:
`
` value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
` ... | byte[n-1];
`
` This byte ordering for multi-byte values is the commonplace network
` byte order or big endian format.
`
`4.2. Miscellaneous
`
` Comments begin with "/*" and end with "*/".
`
` Optional components are denoted by enclosing them in "[[ ]]" double
` brackets.
`
` Single byte entities containing uninterpreted data are of type
` opaque.
`
`4.3. Vectors
`
` A vector (single dimensioned array) is a stream of homogeneous data
` elements. The size of the vector may be specified at documentation
` time or left unspecified until runtime. In either case the length
` declares the number of bytes, not the number of elements, in the
` vector. The syntax for specifying a new type T’ that is a fixed
` length vector of type T is
`
` T T’[n];
`
` Here T’ occupies n bytes in the data stream, where n is a multiple of
` the size of T. The length of the vector is not included in the
` encoded stream.
`
` In the following example, Datum is defined to be three consecutive
` bytes that the protocol does not interpret, while Data is three
` consecutive Datum, consuming a total of nine bytes.
`
` opaque Datum[3]; /* three uninterpreted bytes */
` Datum Data[9]; /* 3 consecutive 3 byte vectors */
`
`Dierks & Allen Standards Track [Page 6]
`
`Petitioner Apple Inc. - Exhibit 1052, p. 6
`
`

`
`RFC 2246 The TLS Protocol Version 1.0 January 1999
`
` Variable length vectors are defined by specifying a subrange of legal
` lengths, inclusively, using the notation <floor..ceiling>. When
` encoded, the actual length precedes the vector’s contents in the byte
` stream. The length will be in the form of a number consuming as many
` bytes as required to hold the vector’s specified maximum (ceiling)
` length. A variable length vector with an actual length field of zero
` is referred to as an empty vector.
`
` T T’<floor..ceiling>;
`
` In the following example, mandatory is a vector that must contain
` between 300 and 400 bytes of type opaque. It can never be empty. The
` actual length field consumes two bytes, a uint16, sufficient to
` represent the value 400 (see Section 4.4). On the other hand, longer
` can represent up to 800 bytes of data, or 400 uint16 elements, and it
` may be empty. Its encoding will include a two byte actual length
` field prepended to the vector. The length of an encoded vector must
` be an even multiple of the length of a single element (for example, a
` 17 byte vector of uint16 would be illegal).
`
` opaque mandatory<300..400>;
` /* length field is 2 bytes, cannot be empty */
` uint16 longer<0..800>;
` /* zero to 400 16-bit unsigned integers */
`
`4.4. Numbers
`
` The basic numeric data type is an unsigned byte (uint8). All larger
` numeric data types are formed from fixed length series of bytes
` concatenated as described in Section 4.1 and are also unsigned. The
` following numeric types are predefined.
`
` uint8 uint16[2];
` uint8 uint24[3];
` uint8 uint32[4];
` uint8 uint64[8];
`
` All values, here and elsewhere in the specification, are stored in
` "network" or "big-endian" order; the uint32 represented by the hex
` bytes 01 02 03 04 is equivalent to the decimal value 16909060.
`
`4.5. Enumerateds
`
` An additional sparse data type is available called enum. A field of
` type enum can only assume the values declared in the definition.
` Each definition is a different type. Only enumerateds of the same
` type may be assigned or compared. Every element of an enumerated must
`
`Dierks & Allen Standards Track [Page 7]
`
`Petitioner Apple Inc. - Exhibit 1052, p. 7
`
`

`
`RFC 2246 The TLS Protocol Version 1.0 January 1999
`
` be assigned a value, as demonstrated in the following example. Since
` the elements of the enumerated are not ordered, they can be assigned
` any unique value, in any order.
`
` enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
`
` Enumerateds occupy as much space in the byte stream as would its
` maximal defined ordinal value. The following definition would cause
` one byte to be used to carry fields of type Color.
`
` enum { red(3), blue(5), white(7) } Color;
`
` One may optionally specify a value without its associated tag to
` force the width definition without defining a superfluous element.
` In the following example, Taste will consume two bytes in the data
` stream but can only assume the values 1, 2 or 4.
`
` enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
`
` The names of the elements of an enumeration are scoped within the
` defined type. In the first example, a fully qualified reference to
` the second element of the enumeration would be Color.blue. Such
` qualification is not required if the target of the assignment is well
` specified.
`
` Color color = Color.blue; /* overspecified, legal */
` Color color = blue; /* correct, type implicit */
`
` For enumerateds that are never converted to external representation,
` the numerical information may be omitted.
`
` enum { low, medium, high } Amount;
`
`4.6. Constructed types
`
` Structure types may be constructed from primitive types for
` convenience. Each specification declares a new, unique type. The
` syntax for definition is much like that of C.
`
` struct {
` T1 f1;
` T2 f2;
` ...
` Tn fn;
` } [[T]];
`
`Dierks & Allen Standards Track [Page 8]
`
`Petitioner Apple Inc. - Exhibit 1052, p. 8
`
`

`
`RFC 2246 The TLS Protocol Version 1.0 January 1999
`
` The fields within a structure may be qualified using the type’s name
` using a syntax much like that available for enumerateds. For example,
` T.f2 refers to the second field of the previous declaration.
` Structure definitions may be embedded.
`
`4.6.1. Variants
`
` Defined structures may have variants based on some knowledge that is
` available within the environment. The selector must be an enumerated
` type that defines the possible variants the structure defines. There
` must be a case arm for every element of the enumeration declared in
` the select. The body of the variant structure may be given a label
` for reference. The mechanism by which the variant is selected at
` runtime is not prescribed by the presentation language.
`
` struct {
` T1 f1;
` T2 f2;
` ....
` Tn fn;
` select (E) {
` case e1: Te1;
` case e2: Te2;
` ....
` case en: Ten;
` } [[fv]];
` } [[Tv]];
`
` For example:
`
` enum { apple, orange } VariantTag;
` struct {
` uint16 number;
` opaque string<0..10>; /* variable length */
` } V1;
` struct {
` uint32 number;
` opaque string[10]; /* fixed length */
` } V2;
` struct {
` select (VariantTag) { /* value of selector is implicit */
` case apple: V1; /* VariantBody, tag = apple */
` case orange: V2; /* VariantBody, tag = orange */
` } variant_body; /* optional label on variant */
` } VariantRecord;
`
` Variant structures may be qualified (narrowed) by specifying a value
` for the selector prior to the type. For example, a
`
`Dierks & Allen Standards Track [Page 9]
`
`Petitioner Apple Inc. - Exhibit 1052, p. 9
`
`

`
`RFC 2246 The TLS Protocol Version 1.0 January 1999
`
` orange VariantRecord
`
` is a narrowed type of a VariantRecord containing a variant_body of
` type V2.
`
`4.7. Cryptographic attributes
`
` The four cryptographic operations digital signing, stream cipher
` encryption, block cipher encryption, and public key encryption are
` designated digitally-signed, stream-ciphered, block-ciphered, and
` public-key-encrypted, respectively. A field’s cryptographic
` processing is specified by prepending an appropriate key word
` designation before the field’s type specification. Cryptographic keys
` are implied by the current session state (see Section 6.1).
`
` In digital signing, one-way hash functions are used as input for a
` signing algorithm. A digitally-signed element is encoded as an opaque
` vector <0..2^16-1>, where the length is specified by the signing
` algorithm and key.
`
` In RSA signing, a 36-byte structure of two hashes (one SHA and one
` MD5) is signed (encrypted with the private key). It is encoded with
` PKCS #1 block type 0 or type 1 as described in [PKCS1].
`
` In DSS, the 20 bytes of the SHA hash are run directly through the
` Digital Signing Algorithm with no additional hashing. This produces
` two values, r and s. The DSS signature is an opaque vector, as above,
` the contents of which are the DER encoding of:
`
` Dss-Sig-Value ::= SEQUENCE {
` r INTEGER,
` s INTEGER
` }
`
` In stream cipher encryption, the plaintext is exclusive-ORed with an
` identical amount of output generated from a cryptographically-secure
` keyed pseudorandom number generator.
`
` In block cipher encryption, every block of plaintext encrypts to a
` block of ciphertext. All block cipher encryption is done in CBC
` (Cipher Block Chaining) mode, and all items which are block-ciphered
` will be an exact multiple of the cipher block length.
`
` In public key encryption, a public key algorithm is used to encrypt
` data in such a way that it can be decrypted only with the matching
` private key. A public-key-encrypted element is encoded as an opaque
` vector <0..2^16-1>, where the length is specified by the signing
` algorithm and key.
`
`Dierks & Allen Standards Track [Page 10]
`
`Petitioner Apple Inc. - Exhibit 1052, p. 10
`
`

`
`RFC 2246 The TLS Protocol Version 1.0 January 1999
`
` An RSA encrypted value is encoded with PKCS #1 block type 2 as
` described in [PKCS1].
`
` In the following example:
`
` stream-ciphered struct {
` uint8 field1;
` uint8 field2;
` digitally-signed opaque hash[20];
` } UserType;
`
` The contents of hash are used as input for the signing algorithm,
` then the entire structure is encrypted with a stream cipher. The
` length of this structure, in bytes would be equal to 2 bytes for
` field1 and field2, plus two bytes for the length of the signature,
` plus the length of the output of the signing algorithm. This is known
` due to the fact that the algorithm and key used for the signing are
` known prior to encoding or decoding this structure.
`
`4.8. Constants
`
` Typed constants can be defined for purposes of specification by
` declaring a symbol of the desired type and assigning values to it.
` Under-specified types (opaque, variable length vectors, and
` structures that contain opaque) cannot be assigned values. No fields
` of a multi-element structure or vector may be elided.
`
` For example,
`
` struct {
` uint8 f1;
` uint8 f2;
` } Example1;
`
` Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */
`
`5. HMAC and the pseudorandom function
`
` A number of operations in the TLS record and handshake layer required
` a keyed MAC; this is a secure digest of some data protected by a
` secret. Forging the MAC is infeasible without knowledge of the MAC
` secret. The construction we use for this operation is known as HMAC,
` described in [HMAC].
`
` HMAC can be used with a variety of different hash algorithms. TLS
` uses it in the handshake with two different algorithms: MD5 and SHA-
` 1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret,
`
`Dierks & Allen Standards Track [Page 11]
`
`Petitioner Apple Inc. - Exhibit 1052, p. 11
`
`

`
`RFC 2246 The TLS Protocol Version 1.0 January 1999
`
` data). Additional hash algorithms can be defined by cipher suites and
` used to protect record data, but MD5 and SHA-1 are hard coded into
` the description of the handshaking for this version of the protocol.
`
` In addition, a construction is required to do expansion of secrets
` into blocks of data for the purposes of key generation or validation.
` This pseudo-random function (PRF) takes as input a secret, a seed,
` and an identifying label and produces an output of arbitrary length.
`
` In order to make the PRF as secure as possible, it uses two hash
` algorithms in a way which should guarantee its security if either
` algorithm remains secure.
`
` First, we define a data expansion function, P_hash(secret, data)
` which uses a single hash function to expand a secret and seed into an
` arbitrary quantity of output:
`
` P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
` HMAC_hash(secret, A(2) + seed) +
` HMAC_hash(secret, A(3) + seed) + ...
`
` Where + indicates concatenation.
`
` A() is defined as:
` A(0) = seed
` A(i) = HMAC_hash(secret, A(i-1))
`
` P_hash can be iterated as many times as is necessary to produce the
` required quantity of data. For example, if P_SHA-1 was being used to
` create 64 bytes of data, it would have to be iterated 4 times
` (through A(4)), creating 80 bytes of output data; the last 16 bytes
` of the final iteration would then be discarded, leaving 64 bytes of
` output data.
`
` TLS’s PRF is created by splitting the secret into two halves and
` using one half to generate data with P_MD5 and the other half to
` generate data with P_SHA-1, then exclusive-or’ing the outputs of
` these two expansion functions together.
`
` S1 and S2 are the two halves of the secret and each is the same
` length. S1 is taken from the first half of the secret, S2 from the
` second half. Their length is created by rounding up the length of the
` overall secret divided by two; thus, if the original secret is an odd
` number of bytes long, the last byte of S1 will be the same as the
` first byte of S2.
`
` L_S = length in bytes of secret;
` L_S1 = L_S2 = ceil(L_S / 2);
`
`Dierks & Allen Standards Track [Page 12]
`
`Petitioner Apple Inc. - Exhibit 1052, p. 12
`
`

`
`RFC 2246 The TLS Protocol Version 1.0 January 1999
`
` The secret is partitioned into two halves (with the possibility of
` one shared byte) as described above, S1 taking the first L_S1 bytes
` and S2 the last L_S2 bytes.
`
` The PRF is then defined as the result of mixing the two pseudorandom
` streams by exclusive-or’ing them together.
`
` PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR
` P_SHA-1(S2, label + seed);
`
` The label is an ASCII string. It should be included in the exact form
` it is given without a length byte or trailing null character. For
` example, the label "slithy toves" would be processed by hashing the
` following bytes:
`
` 73 6C 69 74 68 79 20 74 6F 76 65 73
`
` Note that because MD5 produces 16 byte outputs and SHA-1 produces 20
` byte outputs, the boundaries of their internal iterations will not be
` aligned; to generate a 80 byte output will involve P_MD5 being
` iterated through A(5), while P_SHA-1 will only iterate through A(4).
`
`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.
`
`Dierks & Allen Standards Track [Page 13]
`
`Petitioner Apple Inc. - Exhibit 1052, p. 13
`
`

`
`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