5/9/24, 7:30 AM
`
`RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2
`
`https://datatracker.ietf.org/doc/html/rfc5246
`
`1/104
`
`1
`
`SAMSUNG 1021
`
`Network Working Group T. Dierks
`Request for Comments: 5246 Independent
`Obsoletes:
`3268, 4346, 4366 E. Rescorla
`Updates:
`4492 RTFM, Inc.
`Category: Standards Track August 2008
`The Transport Layer Security (TLS) Protocol
`Version 1.2
`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.
`Abstract
`This document specifies Version 1.2 of the Transport Layer Security
`(TLS) protocol. The TLS protocol provides communications security
`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 ....................................................4
`1.1. Requirements Terminology ...................................5
`1.2. Major Differences from TLS 1.1 .............................5
`2. Goals ...........................................................6
`3. Goals of This Document ..........................................7
`4. Presentation Language ...........................................7
`4.1. Basic Block Size ...........................................7
`4.2. Miscellaneous ..............................................8
`4.3. Vectors ....................................................8
`4.4. Numbers ....................................................9
`4.5. Enumerateds ................................................9
`4.6. Constructed Types .........................................10
`4.6.1. Variants ...........................................10
`4.7. Cryptographic Attributes ..................................12
`4.8. Constants .................................................14
`5. HMAC and the Pseudorandom Function .............................14
`6. The TLS Record Protocol ........................................15
`6.1. Connection States .........................................16
`6.2. Record Layer ..............................................19
`6.2.1. Fragmentation ......................................19
`Dierks & Rescorla Standards Track [Page 1]
`

`

`5/9/24, 7:30 AM
`
`RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2
`
`https://datatracker.ietf.org/doc/html/rfc5246
`
`2/104
`
`2
`
`RFC 5246 TLS August 2008
`6.2.2. Record Compression and Decompression ...............20
`6.2.3. Record Payload Protection ..........................21
`6.2.3.1. Null or Standard Stream Cipher ............22
`6.2.3.2. CBC Block Cipher ..........................22
`6.2.3.3. AEAD Ciphers ..............................24
`6.3. Key Calculation ...........................................25
`7. The TLS Handshaking Protocols ..................................26
`7.1. Change Cipher Spec Protocol ...............................27
`7.2. Alert Protocol ............................................28
`7.2.1. Closure Alerts .....................................29
`7.2.2. Error Alerts .......................................30
`7.3. Handshake Protocol Overview ...............................33
`7.4. Handshake Protocol ........................................37
`7.4.1. Hello Messages .....................................38
`7.4.1.1. Hello Request .............................38
`7.4.1.2. Client Hello ..............................39
`7.4.1.3. Server Hello ..............................42
`7.4.1.4. Hello Extensions ..........................44
`7.4.1.4.1. Signature Algorithms ...........45
`7.4.2. Server Certificate .................................47
`7.4.3. Server Key Exchange Message ........................50
`7.4.4. Certificate Request ................................53
`7.4.5. Server Hello Done ..................................55
`7.4.6. Client Certificate .................................55
`7.4.7. Client Key Exchange Message ........................57
`7.4.7.1. RSA-Encrypted Premaster Secret Message ....58
`7.4.7.2. Client Diffie-Hellman Public Value ........61
`7.4.8. Certificate Verify .................................62
`7.4.9. Finished ...........................................63
`8. Cryptographic Computations .....................................64
`8.1. Computing the Master Secret ...............................64
`8.1.1. RSA ................................................65
`8.1.2. Diffie-Hellman .....................................65
`9. Mandatory Cipher Suites ........................................65
`10. Application Data Protocol .....................................65
`11. Security Considerations .......................................65
`12. IANA Considerations ...........................................65
`Appendix A. Protocol Data Structures and Constant Values ..........68
`A.1. Record Layer ..............................................68
`A.2. Change Cipher Specs Message ...............................69
`A.3. Alert Messages ............................................69
`A.4. Handshake Protocol ........................................70
`A.4.1. Hello Messages .....................................71
`A.4.2. Server Authentication and Key Exchange Messages ....72
`A.4.3. Client Authentication and Key Exchange Messages ....74
`A.4.4. Handshake Finalization Message .....................74
`A.5. The Cipher Suite ..........................................75
`A.6. The Security Parameters ...................................77
`Dierks & Rescorla Standards Track [Page 2]
`

`

`5/9/24, 7:30 AM
`
`RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2
`
`https://datatracker.ietf.org/doc/html/rfc5246
`
`3/104
`
`3
`
`RFC 5246 TLS August 2008
`A.7. Changes to RFC 4492 .......................................78
`Appendix B. Glossary ..............................................78
`Appendix C. Cipher Suite Definitions ..............................83
`Appendix D. Implementation Notes ..................................85
`D.1. Random Number Generation and Seeding ......................85
`D.2. Certificates and Authentication ...........................85
`D.3. Cipher Suites .............................................85
`D.4. Implementation Pitfalls ...................................85
`Appendix E. Backward Compatibility ................................87
`E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 ................87
`E.2. Compatibility with SSL 2.0 ................................88
`E.3. Avoiding Man-in-the-Middle Version Rollback ...............90
`Appendix F. Security Analysis .....................................91
`F.1. Handshake Protocol ........................................91
`F.1.1. Authentication and Key Exchange ....................91
`F.1.1.1. Anonymous Key Exchange ....................91
`F.1.1.2. RSA Key Exchange and Authentication .......92
`F.1.1.3. Diffie-Hellman Key Exchange with
`Authentication ............................
`92
`F.1.2. Version Rollback Attacks ...........................93
`F.1.3. Detecting Attacks Against the Handshake Protocol ...94
`F.1.4. Resuming Sessions ..................................94
`F.2. Protecting Application Data ...............................94
`F.3. Explicit IVs ..............................................95
`F.4. Security of Composite Cipher Modes ........................95
`F.5. Denial of Service .........................................96
`F.6. Final Notes ...............................................96
`Normative References ..............................................
`97
`Informative References ............................................
`98
`Working Group Information ........................................
`101
`Contributors .....................................................
`101
`Dierks & Rescorla Standards Track [Page 3]
`

`

`5/9/24, 7:30 AM
`
`RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2
`
`https://datatracker.ietf.org/doc/html/rfc5246
`
`4/104
`
`4
`
`RFC 5246 TLS August 2008
`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., AES [
`AES], RC4 [SCH], 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-1, etc.) are used for MAC computations. The Record Protocol
`can operate without a MAC, but is generally only used in 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], DSA [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.
`Dierks & Rescorla Standards Track [Page 4]
`

`

`5/9/24, 7:30 AM
`
`RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2
`
`https://datatracker.ietf.org/doc/html/rfc5246
`
`5/104
`
`5
`
`RFC 5246 TLS August 2008
`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 to the judgment of the designers and implementors
`of protocols that run on top of TLS.
`1.1. Requirements Terminology
`The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
`"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
`document are to be interpreted as described in
`RFC 2119 [
`REQ].
`1.2. Major Differences from TLS 1.1
`This document is a revision of the TLS 1.1 [
`TLS1.1] protocol which
`contains improved flexibility, particularly for negotiation of
`cryptographic algorithms. The major changes are:
`- The MD5/SHA-1 combination in the pseudorandom function (PRF) has
`been replaced with cipher-suite-specified PRFs. All cipher suites
`in this document use P_SHA256.
`- The MD5/SHA-1 combination in the digitally-signed element has been
`replaced with a single hash. Signed elements now include a field
`that explicitly specifies the hash algorithm used.
`- Substantial cleanup to the client's and server's ability to
`specify which hash and signature algorithms they will accept.
`Note that this also relaxes some of the constraints on signature
`and hash algorithms from previous versions of TLS.
`- Addition of support for authenticated encryption with additional
`data modes.
`- TLS Extensions definition and AES Cipher Suites were merged in
`from external [
`TLSEXT] and [TLSAES].
`- Tighter checking of EncryptedPreMasterSecret version numbers.
`- Tightened up a number of requirements.
`- Verify_data length now depends on the cipher suite (default is
`still 12).
`- Cleaned up description of Bleichenbacher/Klima attack defenses.
`Dierks & Rescorla Standards Track [Page 5]
`

`

`5/9/24, 7:30 AM
`
`RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2
`
`https://datatracker.ietf.org/doc/html/rfc5246
`
`6/104
`
`6
`
`RFC 5246 TLS August 2008
`- Alerts MUST now be sent in many cases.
`- After a certificate_request, if no certificates are available,
`clients now MUST send an empty certificate list.
`- TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement
`cipher suite.
`- Added HMAC-SHA256 cipher suites.
`- Removed IDEA and DES cipher suites. They are now deprecated and
`will be documented in a separate document.
`- Support for the SSLv2 backward-compatible hello is now a MAY, not
`a SHOULD, with sending it a SHOULD NOT. Support will probably
`become a SHOULD NOT in the future.
`- Added limited "fall-through" to the presentation language to allow
`multiple case arms to have the same encoding.
`- Added an Implementation Pitfalls sections
`- The usual clarifications and editorial work.
`2. Goals
`The goals of the TLS protocol, in order of priority, are as follows:
`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 can 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: preventing
`the need to create a new protocol (and risking the introduction of
`possible new weaknesses) and avoiding 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.
`Dierks & Rescorla Standards Track [Page 6]
`

`

`5/9/24, 7:30 AM
`
`RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2
`
`https://datatracker.ietf.org/doc/html/rfc5246
`
`7/104
`
`7
`
`RFC 5246 TLS August 2008
`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 the various versions of TLS and SSL 3.0 do
`not interoperate (although each protocol incorporates a mechanism by
`which an implementation can back down to prior versions). This
`document is intended primarily for readers who will be implementing
`the protocol and for 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 or of 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; it has
`no 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 byte stream, 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.
`Dierks & Rescorla Standards Track [Page 7]
`

`

`5/9/24, 7:30 AM
`
`RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2
`
`https://datatracker.ietf.org/doc/html/rfc5246
`
`8/104
`
`8
`
`RFC 5246 TLS August 2008
`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
`these are 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, which is
`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
`Dierks & Rescorla Standards Track [Page 8]
`

`

`5/9/24, 7:30 AM
`
`RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2
`
`https://datatracker.ietf.org/doc/html/rfc5246
`
`9/104
`
`9
`
`RFC 5246 TLS August 2008
`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 byte (big-endian) order; the uint32 represented by the hex
`bytes 01 02 03 04 is equivalent to the decimal value 16909060.
`Note that in some cases (e.g., DH parameters) it is necessary to
`represent integers as opaque vectors. In such cases, they are
`represented as unsigned integers (i.e., leading zero octets are not
`required even if the most significant bit is set).
`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;
`An enumerated occupies 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;
`Dierks & Rescorla Standards Track [Page 9]
`

`

`5/9/24, 7:30 AM
`
`RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2
`
`https://datatracker.ietf.org/doc/html/rfc5246
`
`10/104
`
`10
`
`RFC 5246 TLS August 2008
`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]];
`The fields within a structure may be qualified using the type's name,
`with 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. Case arms have limited fall-through: if two case arms
`follow in immediate succession with no fields in between, then they
`Dierks & Rescorla Standards Track [Page 10]
`

`

`5/9/24, 7:30 AM
`
`RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2
`
`https://datatracker.ietf.org/doc/html/rfc5246
`
`11/104
`
`11
`
`RFC 5246 TLS August 2008
`both contain the same fields. Thus, in the example below, "orange"
`and "banana" both contain V2. Note that this is a new piece of
`syntax in TLS 1.2.
`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 e3: case e4: Te3;
`....
`case en: Ten;
`} [[fv]];
`} [[Tv]];
`For example:
`enum { apple, orange, banana } 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:
`case banana:
`V2; /* VariantBody, tag = orange or banana */
`} variant_body; /* optional label on variant */
`} VariantRecord;
`Dierks & Rescorla Standards Track [Page 11]
`

`

`5/9/24, 7:30 AM
`
`RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2
`
`https://datatracker.ietf.org/doc/html/rfc5246
`
`12/104
`
`12
`
`RFC 5246 TLS August 2008
`4.7. Cryptographic Attributes
`The five cryptographic operations -- digital signing, stream cipher
`encryption, block cipher encryption, authenticated encryption with
`additional data (AEAD) encryption, and public key encryption -- are
`designated digitally-signed, stream-ciphered, block-ciphered, aead-
`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).
`A digitally-signed element is encoded as a struct DigitallySigned:
`struct {
`SignatureAndHashAlgorithm algorithm;
`opaque signature<0..2^16-1>;
`} DigitallySigned;
`The algorithm field specifies the algorithm used (see
`Section
`7.4.1.4.1 for the definition of this field). Note that the
`introduction of the algorithm field is a change from previous
`versions. The signature is a digital signature using those
`algorithms over the contents of the element. The contents themselves
`do not appear on the wire but are simply calculated. The length of
`the signature is specified by the signing algorithm and key.
`In RSA signing, the opaque vector contains the signature generated
`using the RSASSA-PKCS1-v1_5 signature scheme defined in [
`PKCS1]. As
`discussed in [
`PKCS1], the DigestInfo MUST be DER-encoded [X680]
`[
`X690]. For hash algorithms without parameters (which includes
`SHA-1), the DigestInfo.AlgorithmIdentifier.parameters field MUST be
`NULL, but implementations MUST accept both without parameters and
`with NULL parameters. Note that earlier versions of TLS used a
`different RSA signature scheme that did not include a DigestInfo
`encoding.
`In DSA, the 20 bytes of the SHA-1 hash are run directly through the
`Digital Signing Algorithm with no additional hashing. This produces
`two values, r and s. The DSA signature is an opaque vector, as
`above, the contents of which are the DER encoding of:
`Dss-Sig-Value ::= SEQUENCE {
`r INTEGER,
`s INTEGER
`}
`Dierks & Rescorla Standards Track [Page 12]
`

`

`5/9/24, 7:30 AM
`
`RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2
`
`https://datatracker.ietf.org/doc/html/rfc5246
`
`13/104
`
`13
`
`RFC 5246 TLS August 2008
`Note: In current terminology, DSA refers to the Digital Signature
`Algorithm and DSS refers to the NIST standard. In the original SSL
`and TLS specs, "DSS" was used universally. This document uses "DSA"
`to refer to the algorithm, "DSS" to refer to the standard, and it
`uses "DSS" in the code point definitions for historical continuity.
`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 that are block-ciphered
`will be an exact multiple of the cipher block length.
`In AEAD encryption, the plaintext is simultaneously encrypted and
`integrity protected. The input may be of any length, and aead-
`ciphered output is generally larger than the input in order to
`accommodate the integrity check value.
`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 encryption
`algorithm and key.
`RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme
`defined in [
`PKCS1].
`In the following example
`stream-ciphered struct {
`uint8 field1;
`uint8 field2;
`digitally-signed opaque {
`uint8 field3<0..255>;
`uint8 field4;
`};
`} UserType;
`The contents of the inner struct (field3 and field4) are used as
`input for the signature/hash algorithm, and then the entire structure
`is encrypted with a stream cipher. The length of this structure, in
`bytes, would be equal to two bytes for field1 and field2, plus two
`bytes for the signature and hash algorithm, plus two bytes for the
`length of the signature, plus the length of the output of the signing
`Dierks & Rescorla Standards Track [Page 13]
`

`

`5/9/24, 7:30 AM
`
`RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2
`
`https://datatracker.ietf.org/doc/html/rfc5246
`
`14/104
`
`14
`
`RFC 5246 TLS August 2008
`algorithm. The length of the signature is known because 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
`The TLS record layer uses a keyed Message Authentication Code (MAC)
`to protect message integrity. The cipher suites defined in this
`document use a construction known as HMAC, described in [
`HMAC], which
`is based on a hash function. Other cipher suites MAY define their
`own MAC constructions, if needed.
`In addition, a construction is required to do expansion of secrets
`into blocks of data for the purposes of key generation or validation.
`This pseudorandom function (PRF) takes as input a secret, a seed, and
`an identifying label and produces an output of arbitrary length.
`In this section, we define one PRF, based on HMAC. This PRF with the
`SHA-256 hash function is used for all cipher suites defined in this
`document and in TLS documents published prior to this document when
`TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a
`PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a
`stronger standard hash function.
`First, we define a data expansion function, P_hash(secret, data),
`that uses a single hash function to expand a secret and seed into an
`arbitrary quantity of output:
`Dierks & Rescorla Standards Track [Page 14]
`

`

`5/9/24, 7:30 AM
`
`RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2
`
`https://datatracker.ietf.org/doc/html/rfc5246
`
`15/104
`
`15
`
`RFC 5246 TLS August 2008
`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 necessary to produce the
`required quantity of data. For example, if P_SHA256 is being used to
`create 80 bytes of data, it will have to be iterated three times
`(through A(3)), creating 96 bytes of output data; the last 16 bytes
`of the final iteration will then be discarded, leaving 80 bytes of
`output data.
`TLS's PRF is created by applying P_hash to the secret as:
`PRF(secret, label, seed) = P_<hash>(secret, label + seed)
`The label is an ASCII string. It should be included in the exact
`form it is given without a length byte or tr