`
`>
`
`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]
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/IN8L8581.htm
`
`5/28/2013
`
`Petitioner Apple - Ex. 1032, p. 1
`
`
`
`Page 2 of 75
`
`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]
`RFC 2246 The TLS Protocol Version 1.0 January 1999
`
`D. Implementation Notes 64
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/IN8L8581.htm
`
`5/28/2013
`
`Petitioner Apple - Ex. 1032, p. 2
`
`
`
`Page 3 of 75
`
`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]
`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
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/IN8L8581.htm
`
`5/28/2013
`
`Petitioner Apple - Ex. 1032, p. 3
`
`
`
`Page 4 of 75
`
`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]
`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
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/IN8L8581.htm
`
`5/28/2013
`
`Petitioner Apple - Ex. 1032, p. 4
`
`
`
`Page 5 of 75
`
`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]
`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.
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/IN8L8581.htm
`
`5/28/2013
`
`Petitioner Apple - Ex. 1032, p. 5
`
`
`
`Page 6 of 75
`
`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]
`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
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/IN8L8581.htm
`
`5/28/2013
`
`Petitioner Apple - Ex. 1032, p. 6
`
`
`
`Page 7 of 75
`
`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]
`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
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/IN8L8581.htm
`
`5/28/2013
`
`Petitioner Apple - Ex. 1032, p. 7
`
`
`
`Page 8 of 75
`
`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]
`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;
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/IN8L8581.htm
`
`5/28/2013
`
`Petitioner Apple - Ex. 1032, p. 8
`
`
`
`Page 9 of 75
`
`} [[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]
`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:
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/IN8L8581.htm
`
`5/28/2013
`
`Petitioner Apple - Ex. 1032, p. 9
`
`
`
`Page 10 of 75
`
`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]
`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;
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/IN8L8581.htm
`
`5/28/2013
`
`Petitioner Apple - Ex. 1032, p. 10
`
`
`
`Page 11 of 75
`
`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]
`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
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/IN8L8581.htm
`
`5/28/2013
`
`Petitioner Apple - Ex. 1032, p. 11
`
`
`
`Page 12 of 75
`
`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]
`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
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/IN8L8581.htm
`
`5/28/2013
`
`Petitioner Apple - Ex. 1032, p. 12
`
`
`
`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.
`
`Page 13 of 75
`
`Dierks & Allen Standards Track [Page 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 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.
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/IN8L8581.htm
`
`5/28/2013
`
`Petitioner Apple - Ex. 1032, p. 13
`
`
`
`Page 14 of 75
`
`client random
`A 32 byte value provided by the client.
`
`Dierks & Allen Standards Track [Page 14]
`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;
`enum { true, false } IsExportable;