Transport Layer Security Working Group
`INTERNET-DRAFT
`Expire in six months
`
`Alan O. Freier
`Netscape Communications
`Philip Karlton
`Netscape Communications
`Paul C. Kocher
`Independent Consultant
`November 18, 1996
`
`The SSL Protocol
`Version 3.0
`
`<draft-ietf-tls-ssl-version3-00.txt>
`
`Status of this memo
`
` This document is an Internet-Draft. Internet-Drafts are working
` documents of the Internet Engineering Task Force (IETF), its areas,
` and its working groups. Note that other groups may also distribute
` working documents as Internet- Drafts.
`
` Internet-Drafts are draft documents valid for a maximum of six
` months and may be updated, replaced, or made obsolete by other
` documents at any time. It is inappropriate to use Internet-Drafts
` as reference material or to cite them other than as work in
` progress.
`
` To learn the current status of any Internet-Draft, please check the
` 1id-abstracts.txt listing contained in the Internet Drafts Shadow
` Directories on ds.internic.net (US East Coast), nic.nordu.net
` (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
` Rim).
`
`Abstract
`
` This document specifies Version 3.0 of the Secure Sockets Layer
` (SSL V3.0) protocol, a security protocol that 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.
`
`Freier, Karlton, Kocher
`
`[Page 1]
`
`Juniper Ex. 1040-p. 1
`Juniper v Implicit
`
`

`

`
`INTERNET-DRAFT SSL 3.0 November 18, 1996
`
`Table of Contents
` Status of this memo 1
` Abstract 1
` Table of Contents 2
` 1. Introduction 4
` 2. Goals 4
` 3. Goals of this document 5
` 4. Presentation language 5
` 4.1 Basic block size 5
` 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 8
` 4.7 Cryptographic attributes 9
` 4.8 Constants 10
` 5. SSL protocol 10
` 5.1 Session and connection states 10
` 5.2 Record layer 12
` 5.2.1 Fragmentation 12
` 5.2.2 Record compression and decompression 13
` 5.2.3 Record payload protection and the CipherSpec 13
` 5.2.3.1 Null or standard stream cipher 14
` 5.2.3.2 CBC block cipher 15
` 5.3 Change cipher spec protocol 16
` 5.4 Alert protocol 16
` 5.4.1 Closure alerts 17
` 5.4.2 Error alerts 17
` 5.5 Handshake protocol overview 18
` 5.6 Handshake protocol 20
` 5.6.1 Hello messages 21
` 5.6.1.1 Hello request 21
` 5.6.1.2 Client hello 21
` 5.6.1.3 Server hello 24
` 5.6.2 Server certificate 25
` 5.6.3 Server key exchange message 25
` 5.6.4 Certificate request 27
` 5.6.5 Server hello done 27
` 5.6.6 Client certificate 28
` 5.6.7 Client key exchange message 28
` 5.6.7.1 RSA encrypted premaster secret message 28
` 5.6.7.2 FORTEZZA key exchange message 29
` 5.6.7.3 Client Diffie-Hellman public value 30
` 5.6.8 Certificate verify 30
` 5.6.9 Finished 31
` 5.7 Application data protocol 32
` 6. Cryptographic computations 32
` 6.1 Asymmetric cryptographic computations 32
` 6.1.1 RSA 32
` 6.1.2 Diffie-Hellman 33
` 6.1.3 FORTEZZA 33
`
`Freier, Karlton, Kocher [Page 2]
`
`Juniper Ex. 1040-p. 2
`Juniper v Implicit
`
`

`

`
`INTERNET-DRAFT SSL 3.0 November 18, 1996
`
` 6.2 Symmetric cryptographic calculations and the CipherSpec 33
` 6.2.1 The master secret 33
` 6.2.2 Converting the master secret into keys and MAC 33
` 6.2.2.1 Export key generation example 35
` A. Protocol constant values 36
` A.1 Reserved port assignments 36
` A.1.1 Record layer 36
` A.2 Change cipher specs message 37
` A.3 Alert messages 37
` A.4 Handshake protocol 37
` A.4.1 Hello messages 38
` A.4.2 Server authentication and key exchange messages 39
` A.5 Client authentication and key exchange messages 40
` A.5.1 Handshake finalization message 41
` A.6 The CipherSuite 41
` A.7 The CipherSpec 42
` B. Glossary 44
` C. CipherSuite definitions 47
` D. Implementation Notes 49
` D.1 Temporary RSA keys 49
` D.2 Random Number Generation and Seeding 49
` D.3 Certificates and authentication 50
` D.4 CipherSuites 50
` D.5 FORTEZZA 50
` D.5.1 Notes on use of FORTEZZA hardware 50
` D.5.2 FORTEZZA Ciphersuites 51
` D.5.3 FORTEZZA Session resumption 51
` E. Version 2.0 Backward Compatibility 52
` E.1 Version 2 client hello 52
` E.2 Avoiding man-in-the-middle version rollback 53
` F. Security analysis 55
` F.1 Handshake protocol 55
` F.1.1 Authentication and key exchange 55
` F.1.1.1 Anonymous key exchange 55
` F.1.1.2 RSA key exchange and authentication 56
` F.1.1.3 Diffie-Hellman key exchange with authentication 57
` F.1.1.4 FORTEZZA 57
` F.1.2 Version rollback attacks 57
` F.1.3 Detecting attacks against the handshake protocol 58
` F.1.4 Resuming sessions 58
` F.1.5 MD5 and SHA 58
` F.2 Protecting application data 59
` F.3 Final notes 59
` G. Patent Statement 60
` References 61
` Authors 62
`
`Freier, Karlton, Kocher [Page 3]
`
`Juniper Ex. 1040-p. 3
`Juniper v Implicit
`
`

`

`
`INTERNET-DRAFT SSL 3.0 November 18, 1996
`
`1. Introduction
`
` The primary goal of the SSL Protocol is to provide privacy and
` reliability between two communicating applications. The protocol
` is composed of two layers. At the lowest level, layered on top of
` some reliable transport protocol (e.g., TCP[TCP]), is the SSL
` Record Protocol. The SSL Record Protocol is used for encapsulation
` of various higher level protocols. One such encapsulated protocol,
` the SSL 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. One advantage of SSL is that it
` is application protocol independent. A higher level protocol can
` layer on top of the SSL Protocol transparently. The SSL protocol
` provides connection security that has three basic properties:
`
` - The connection is private. Encryption is used after an
` initial handshake to define a secret key. Symmetric
` cryptography is used for data encryption (e.g., DES[DES],
` RC4[RC4], etc.)
` - The peer’s identity can be authenticated using asymmetric, or
` public key, cryptography (e.g., RSA[RSA], DSS[DSS], etc.).
` - 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.
`
`2. Goals
`
` The goals of SSL Protocol v3.0, in order of their priority,
` are:
` 1. Cryptographic security
` SSL should be used to establish a secure
` connection between two parties.
` 2. Interoperability
` Independent programmers should be able to
` develop applications utilizing SSL 3.0 that
` will then be able to successfully exchange
` cryptographic parameters without knowledge of
` one another’s code.
`
` Note: It is not the case that all instances of SSL (even
` in the same application domain) will be able to
` successfully connect. For instance, if the server
` supports a particular hardware token, and the client
` does not have access to such a token, then the
` connection will not succeed.
`
` 3. Extensibility SSL 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 the need
`
`Freier, Karlton, Kocher [Page 4]
`
`Juniper Ex. 1040-p. 4
`Juniper v Implicit
`
`

`

`
`INTERNET-DRAFT SSL 3.0 November 18, 1996
`
` 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 SSL 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
`
` The SSL Protocol Version 3.0 Specification is intended primarily
` for readers who will be implementing the protocol and those doing
` cryptographic analysis of it. The spec 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 SSL only,
` not to have general application beyond that particular goal.
`
`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.
`
`Freier, Karlton, Kocher [Page 5]
`
`Juniper Ex. 1040-p. 5
`Juniper v Implicit
`
`

`

`
`INTERNET-DRAFT SSL 3.0 November 18, 1996
`
`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 */
`
` 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.
`
` opaque mandatory<300..400>;
` /* length field is 2 bytes, cannot be empty */
` uint16 longer<0..800>;
` /* zero to 400 16-bit unsigned integers */
`
`Freier, Karlton, Kocher [Page 6]
`
`Juniper Ex. 1040-p. 6
`Juniper v Implicit
`
`

`

`
`INTERNET-DRAFT SSL 3.0 November 18, 1996
`
`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];
`
`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 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;
`
`Freier, Karlton, Kocher [Page 7]
`
`Juniper Ex. 1040-p. 7
`Juniper v Implicit
`
`

`

`
`INTERNET-DRAFT SSL 3.0 November 18, 1996
`
`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]];
`
` 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;
`
`Freier, Karlton, Kocher [Page 8]
`
`Juniper Ex. 1040-p. 8
`Juniper v Implicit
`
`

`

`
`INTERNET-DRAFT SSL 3.0 November 18, 1996
`
` 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
`
` 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 5.1).
`
` In digital signing, one-way hash functions are used as input for a
` signing algorithm. In RSA signing, a 36-byte structure of two
` hashes (one SHA and one MD5) is signed (encrypted with the private
` key). In DSS, the 20 bytes of the SHA hash are run directly
` through the Digital Signing Algorithm with no additional hashing.
`
` 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. Because it is unlikely that the plaintext
` (whatever data is to be sent) will break neatly into the necessary
` block size (usually 64 bits), it is necessary to pad out the end of
` short blocks with some regular pattern, usually all zeroes.
`
` In public key encryption, one-way functions with secret "trapdoors"
` are used to encrypt the outgoing data. Data encrypted with the
` public key of a given key pair can only be decrypted with the
` private key, and vice-versa. In the following example:
`
`Freier, Karlton, Kocher [Page 9]
`
`Juniper Ex. 1040-p. 9
`Juniper v Implicit
`
`

`

`
`INTERNET-DRAFT SSL 3.0 November 18, 1996
`
` 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.
`
`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. SSL protocol
`
` SSL is a layered protocol. At each layer, messages may include
` fields for length, description, and content. SSL 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.
`
`5.1 Session and connection states
`
` An SSL session is stateful. It is the responsibility of the SSL
` Handshake protocol to coordinate the states of the client and
` server, thereby allowing the protocol state machines of each to
` operate consistently, despite the fact that the state is not
` exactly parallel. Logically the state is represented twice, once
` as the current operating state, and (during the handshake protocol)
` again as the pending state. Additionally, separate read and write
` states are maintained. When the client or server receives a change
` cipher spec message, it copies the pending read state into the
` current read state. When the client or server sends a change
` cipher spec message, it copies the pending write state into the
` current write state. When the handshake negotiation is complete,
` the client and server exchange change cipher spec messages (see
` Section 5.3), and they then communicate using the newly agreed-upon
` cipher spec.
`
`Freier, Karlton, Kocher [Page 10]
`
`Juniper Ex. 1040-p. 10
`Juniper v Implicit
`
`

`

`
`INTERNET-DRAFT SSL 3.0 November 18, 1996
`
` An SSL session may include multiple secure connections; in
` addition, parties may have multiple simultaneous sessions.
`
` The session state includes the following elements:
`
` session identifier
` An arbitrary byte sequence chosen by the server
` to identify an active or resumable session
` state.
` peer certificate X509.v3[X509] certificate of the peer. This
` element of the state may be null.
` compression method
` The algorithm used to compress data prior to
` encryption.
` cipher spec Specifies the bulk data encryption algorithm
` (such as null, DES, etc.) and a MAC algorithm
` (such as MD5 or SHA). It also defines
` cryptographic attributes such as the hash_size.
` (See Appendix A.7 for formal definition)
` master secret 48-byte secret shared between the client and
` server.
` is resumable A flag indicating whether the session can be
` used to initiate new connections.
`
` The connection state includes the following elements:
`
` server and client random
` Byte sequences that are chosen by the server
` and client for each connection.
` server write MAC secret
` The secret used in MAC operations on data
` written by the server
` client write MAC secret
` The secret used in MAC operations on data
` written by the client.
` server write key The bulk cipher key for data encrypted by the
` server and decrypted by the client.
` client write key The bulk cipher key for data encrypted by the
` client and decrypted by the server.
` initialization vectors
` When a block cipher in CBC mode is used, an
` initialization vector (IV) is maintained for
` each key. This field is first initialized by
` the SSL handshake protocol. Thereafter the
` final ciphertext block from each record is
` preserved for use with the following record.
` sequence numbers Each party maintains separate sequence numbers
` for transmitted and received messages for each
` connection. When a party sends or receives a
` change cipher spec message, the appropriate
` sequence number is set to zero. Sequence
`
`Freier, Karlton, Kocher [Page 11]
`
`Juniper Ex. 1040-p. 11
`Juniper v Implicit
`
`

`

`
`INTERNET-DRAFT SSL 3.0 November 18, 1996
`
` numbers are of type uint64 and may not exceed
` 2^64-1.
`
`5.2 Record layer
`
` The SSL Record Layer receives uninterpreted data from higher layers
` in non-empty blocks of arbitrary size.
`
`5.2.1 Fragmentation
`
` The record layer fragments information blocks into SSLPlaintext
` records of 2^14 bytes or less. Client message boundaries are not
` preserved in the record layer (i.e., multiple client messages of
` the same ContentType may be coalesced into a single SSLPlaintext
` record).
`
` struct {
` uint8 major, minor;
` } ProtocolVersion;
`
` enum {
` change_cipher_spec(20), alert(21), handshake(22),
` application_data(23), (255)
` } ContentType;
`
` struct {
` ContentType type;
` ProtocolVersion version;
` uint16 length;
` opaque fragment[SSLPlaintext.length];
` } SSLPlaintext;
`
` type The higher level protocol used to process the
` enclosed fragment.
` version The version of protocol being employed. This
` document describes SSL Version 3.0 (See
` Appendix A.1.1).
` length The length (in bytes) of the following
` SSLPlaintext.fragment. The length should not
` exceed 2^14.
` fragment The application data. This data is transparent
` and treated as an independent block to be dealt
` with by the higher level protocol specified by
` the type field.
`
` Note: Data of different SSL Record layer content types may
` be interleaved. Application data is generally of
` lower precedence for transmission than other content
` types.
`
`Freier, Karlton, Kocher [Page 12]
`
`Juniper Ex. 1040-p. 12
`Juniper v Implicit
`
`

`

`
`INTERNET-DRAFT SSL 3.0 November 18, 1996
`
`5.2.2 Record compression and decompression
`
` All records are compressed using the compression algorithm defined
` in the current session state. There is always an active
` compression algorithm, however initially it is defined as
` CompressionMethod.null. The compression algorithm translates an
` SSLPlaintext structure into an SSLCompressed structure.
` Compression functions erase their state information whenever the
` CipherSpec is replaced.
`
` Note: The CipherSpec is part of the session state
` described in Section 5.1. References to fields of
` the CipherSpec are made throughout this document
` using presentation syntax. A more complete
` description of the CipherSpec is shown in Appendix
` A.7.
`
` Compression must be lossless and may not increase the content
` length by more than 1024 bytes. If the decompression function
` encounters an SSLCompressed.fragment that would decompress to a
` length in excess of 2^14 bytes, it should issue a fatal
` decompression_failure alert (Section 5.4.2).
`
` struct {
` ContentType type; /* same as SSLPlaintext.type */
` ProtocolVersion version;/* same as SSLPlaintext.version */
` uint16 length;
` opaque fragment[SSLCompressed.length];
` } SSLCompressed;
`
` length The length (in bytes) of the following
` SSLCompressed.fragment. The length
` should not exceed 2^14 + 1024.
` fragment The compressed form of
` SSLPlaintext.fragment.
`
` Note: A CompressionMethod.null operation is an identity
` operation; no fields are altered.
` (See Appendix A.4.1)
`
` Implementation note:
` Decompression functions are responsible for
` ensuring that messages cannot cause internal buffer
` overflows.
`
`5.2.3 Record payload protection and the CipherSpec
`
` All records are protected using the encryption and MAC algorithm