ietf-corpus

rfc-5246

The Transport Layer Security (TLS) Protocol Version 1.2

T. Dierks, E. Rescorla
date2008-08 streamIETF areasec wgtls statusPROPOSED STANDARD pages104 canonicalhttps://www.rfc-editor.org/rfc/rfc5246 doi10.17487/RFC5246 errataview
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. [STANDARDS-TRACK]

obsoleted by

obsoletes

updated by

updates

Extracted elements (30)

design-rationale §1.2

AEAD cipher support was added in TLS 1.2 to allow authenticated encryption modes (e.g., AES-GCM, AES-CCM) that provide both confidentiality and integrity in a single primitive, eliminating the separate MAC computation required by stream and CBC modes.

tls, crypto

design-rationale §1.2

TLS 1.2 replaced the TLS 1.1 composite MD5/SHA-1 PRF and signature hash with cipher-suite-specified PRFs and an explicit SignatureAndHashAlgorithm field, improving cryptographic agility and removing reliance on MD5 whose collision resistance was already weakened.

tls, crypto

interoperability-note §E.1

TLS 1.2 peers interoperating with TLS 1.0/1.1 or SSL 3.0 negotiate version via the ClientHello/ServerHello version fields. Support for the SSLv2 backward-compatible ClientHello format is now MAY (not SHOULD), with sending it explicitly SHOULD NOT, anticipating eventual removal.

tls

normative-requirement §6.2.3.3 MUST

If AEAD decryption fails, a fatal bad_record_mac alert MUST be generated.

tls, security

normative-requirement §6.2.1 MUST NOT

Implementations MUST NOT send zero-length fragments of Handshake, Alert, or ChangeCipherSpec content types. Zero-length Application data fragments MAY be sent as a traffic analysis countermeasure.

tls

normative-requirement §5 MUST

New cipher suites MUST explicitly specify a PRF and SHOULD use the TLS PRF with SHA-256 or a stronger standard hash function.

tls, crypto

normative-requirement §6.2.3.2 MUST

The CBC IV SHOULD be chosen at random and MUST be unpredictable. This replaces the TLS 1.0 practice of using the previous record's last ciphertext block as the IV, which was vulnerable to the CBCATT chosen-plaintext attack.

tls, crypto, security

normative-requirement §7.2.2 MUST NOT

The decryption_failed_RESERVED, no_certificate_RESERVED, and export_restriction_RESERVED alert codes MUST NOT be sent by compliant implementations; decryption_failed in particular could permit CBC padding oracle attacks.

tls, security

normative-requirement §7.4.9 MUST

The Finished message verify_data is PRF(master_secret, finished_label, Hash(handshake_messages)); default length is 12 bytes but cipher suites may specify otherwise. Both peers MUST verify the peer's Finished message before the handshake is considered complete.

tls, crypto

normative-requirement §6.1 MUST

The sequence number MUST be set to zero whenever a connection state is made active. Sequence numbers MUST NOT wrap; if an implementation would need to wrap, it must renegotiate instead.

tls

normative-requirement §9 REQUIRED

TLS_RSA_WITH_AES_128_CBC_SHA is the mandatory-to-implement cipher suite for TLS 1.2, replacing TLS_RSA_WITH_3DES_EDE_CBC_SHA. IDEA and DES cipher suites are removed as deprecated.

tls, crypto

normative-requirement §7.2.2 MUST

Upon transmission or receipt of a fatal alert, both parties MUST immediately close the connection and MUST forget all session identifiers, keys, and secrets associated with the failed connection; connections terminated with a fatal alert MUST NOT be resumed.

tls, security

normative-requirement §7.4.6 MUST

When a client receives a CertificateRequest but has no suitable certificate, it MUST send an empty Certificate message rather than omitting it or sending a no_certificate alert (which is reserved for SSLv3 only).

tls, pkix

protocol-element §6.1

A TLS connection has four logical states: current read, current write, pending read, and pending write. Each state holds a compression algorithm, cipher state, MAC key, and a per-direction sequence number (uint64). Security parameters include a 48-byte master secret and 32-byte client/server randoms.

tls

protocol-element §7.2

Alert messages carry AlertLevel (warning=1 or fatal=2) and AlertDescription (a defined enum including close_notify, bad_record_mac, handshake_failure, certificate_*, protocol_version, etc.). Fatal alerts cause immediate connection termination and session invalidation.

tls

protocol-element §6.3

Key material is derived by computing key_block = PRF(master_secret, "key expansion", server_random + client_random) and partitioning it into client/server write MAC keys, encryption keys, and IVs in that order. AES_256_CBC_SHA256 requires the most material at 128 bytes total.

tls, crypto

protocol-element §7.1

The ChangeCipherSpec message is a single byte of value 1 sent under the current (not pending) cipher spec. Upon sending, the sender MUST immediately make the write pending state the write active state; upon reception, the receiver copies the read pending state to the read current state.

tls

protocol-element §5

TLS 1.2 defines a PRF as PRF(secret, label, seed) = P_SHA256(secret, label + seed), where P_hash iterates HMAC over a chain A(0)=seed, A(i)=HMAC_hash(secret, A(i-1)). This replaces the TLS 1.1 dual-hash (MD5+SHA-1) PRF with a cipher-suite-specified construction, defaulting to SHA-256.

tls, crypto

registry §12

This document directs IANA to maintain the following TLS registries: TLS Content Type, TLS Handshake Type, TLS Alert Description, TLS Cipher Suite, TLS Compression Method, and TLS ExtensionType. Additions generally require IETF Review or Standards Action.

tls, registry

security-consideration §7.4.7.1

RSA-encrypted PreMaster Secret: the client-offered version number inside the PKCS#1-encrypted blob must be checked against the version in ClientHello; TLS 1.2 tightened this check and prescribes generating a random premaster secret on mismatch (rather than aborting) to prevent Bleichenbacher-style version oracle attacks.

tls, security, crypto

security-consideration §6.1

The TLS record type and length fields are not protected by encryption. Applications sensitive to traffic-analysis attacks should consider padding or cover traffic, as an observer can always see content-type boundaries and record sizes.

tls, security, privacy

security-consideration §6.2.3.2

To defend against the CBCTIME MAC timing attack (Canvel et al.), implementations MUST ensure that record processing time is essentially the same whether or not the padding is correct — the best approach is to compute the MAC even when padding is invalid and only then reject the record.

tls, security, crypto

security-consideration §F.1.2

Version rollback protection relies on the Finished message binding the negotiated parameters: an attacker who downgrades the version or cipher suite will cause the Finished hashes to mismatch, aborting the connection. However, higher-level protocols must still enforce minimum acceptable versions, as TLS itself does not reject negotiation of weaker modes.

tls, security

state-machine §7.3

Abbreviated handshake (session resumption): client sends ClientHello with a known Session ID; if the server finds a match, it sends ServerHello with the same Session ID; both sides immediately exchange ChangeCipherSpec and Finished without re-running key exchange.

tls

state-machine §7.3

Full TLS handshake: client sends ClientHello; server responds with ServerHello, Certificate*, ServerKeyExchange*, CertificateRequest*, ServerHelloDone; client sends Certificate*, ClientKeyExchange, CertificateVerify*, ChangeCipherSpec, Finished; server responds with ChangeCipherSpec, Finished. Application data MUST NOT be sent before the first handshake completes.

tls

wire-format §4.7

DigitallySigned structure introduced in TLS 1.2: SignatureAndHashAlgorithm (hash_algorithm byte + signature_algorithm byte) followed by opaque signature<0..2^16-1>. The explicit algorithm field is new versus TLS 1.1's implicit MD5+SHA-1.

tls, crypto, pkix

wire-format §6.2.3.3

GenericAEADCipher: nonce_explicit (SecurityParameters.record_iv_length bytes) followed by aead-ciphered content. Additional authenticated data is seq_num || TLSCompressed.type || TLSCompressed.version || TLSCompressed.length. No separate MAC key is used; AEAD expansion MUST NOT exceed 1024 bytes.

tls, crypto

wire-format §6.2.3.2

GenericBlockCipher for CBC mode: explicit IV (SecurityParameters.record_iv_length bytes, equal to block_size), followed by block-ciphered struct containing content, MAC, padding bytes (each byte MUST equal padding_length), and padding_length (uint8). Total ciphertext length must be a multiple of the block length.

tls, crypto

wire-format §7.4

Handshake message framing: HandshakeType (1 byte enum: hello_request=0 through finished=20), uint24 length, and a body variant-selected by type. Messages MUST arrive in the prescribed order; an unexpected order is a fatal error.

tls

wire-format §6.2.1

TLSPlaintext record: ContentType (1 byte, e.g. handshake=22, application_data=23), ProtocolVersion (major=3, minor=3 for TLS 1.2, 2 bytes), length (uint16, MUST NOT exceed 2^14), and opaque fragment. TLS version {3,3} reflects the historical SSL numbering.

tls