Skip to main content

9. Compliance Requirements

9.1. Mandatory-to-Implement Cipher Suites​

In the absence of an application profile standard specifying otherwise:

A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see Appendix B.4).

A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].

9.2. Mandatory-to-Implement Extensions​

In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the following TLS extensions:

  • Supported Versions ("supported_versions"; Section 4.2.1)
  • Cookie ("cookie"; Section 4.2.2)
  • Signature Algorithms ("signature_algorithms"; Section 4.2.3)
  • Signature Algorithms Certificate ("signature_algorithms_cert"; Section 4.2.3)
  • Negotiated Groups ("supported_groups"; Section 4.2.7)
  • Key Share ("key_share"; Section 4.2.8)
  • Server Name Indication ("server_name"; Section 3 of [RFC6066])

All implementations MUST send and use these extensions when offering applicable features:

  • "supported_versions" is REQUIRED for all ClientHello, ServerHello, and HelloRetryRequest messages.

  • "signature_algorithms" is REQUIRED for certificate authentication.

  • "supported_groups" is REQUIRED for ClientHello messages using DHE or ECDHE key exchange.

  • "key_share" is REQUIRED for DHE or ECDHE key exchange.

  • "pre_shared_key" is REQUIRED for PSK key agreement.

  • "psk_key_exchange_modes" is REQUIRED for PSK key agreement.

A client is considered to be attempting to negotiate using this specification if the ClientHello contains a "supported_versions" extension with 0x0304 contained in its body. Such a ClientHello message MUST meet the following requirements:

  • If not containing a "pre_shared_key" extension, it MUST contain both a "signature_algorithms" extension and a "supported_groups" extension.

  • If containing a "supported_groups" extension, it MUST also contain a "key_share" extension, and vice versa. An empty KeyShare.client_shares vector is permitted.

Servers receiving a ClientHello which does not conform to these requirements MUST abort the handshake with a "missing_extension" alert.

In addition, all implementations MUST support use of the "server_name" extension with applications capable of using it. Servers MAY require clients to send a valid "server_name" extension. Servers requiring this extension SHOULD respond to a ClientHello lacking a "server_name" extension by terminating the connection with a "missing_extension" alert.

9.3. Protocol Invariants​

This section describes invariants that TLS endpoints and middleboxes MUST follow to ensure the interoperability of the protocol.

TLS is designed to be usable in a wide variety of networking environments, including in the presence of middleboxes (e.g., firewalls, proxies, and network address translators) that do not understand the TLS protocol. These middleboxes may examine certain aspects of TLS connections and may take actions based on what they observe. To maximize interoperability, TLS 1.3 implementations MUST adhere to certain protocol invariants to ensure that middleboxes do not misunderstand the connection.

The following are key protocol invariants in TLS 1.3:

Record Layer Invariants​

The TLS record layer MUST adhere to the following invariants:

  1. Record Version: All records (except the initial ClientHello) MUST have legacy_record_version set to 0x0303 (TLS 1.2). The initial ClientHello MAY have this field set to 0x0301 (TLS 1.0) for maximum compatibility.

  2. Content Type: All encrypted records MUST have the outer content type set to application_data (23). The actual content type is in TLSInnerPlaintext.

  3. Record Size: Unencrypted TLSPlaintext records MUST NOT exceed 2^14 bytes. Encrypted TLSCiphertext records MUST NOT exceed 2^14 + 256 bytes.

Handshake Invariants​

The TLS handshake MUST adhere to the following invariants:

  1. Extension Ordering: The "pre_shared_key" extension MUST be the last extension in the ClientHello.

  2. Message Ordering: Handshake messages MUST be sent in the order specified in Section 4.

  3. Key Change Boundaries: Certain messages (ClientHello, EndOfEarlyData, ServerHello, Finished, KeyUpdate) MUST align with record boundaries.

Middlebox Compatibility​

For compatibility with legacy middleboxes, TLS 1.3 implementations:

  1. MUST send a change_cipher_spec record (as a separate record) after the ServerHello for middlebox compatibility.

  2. MAY ignore unexpected change_cipher_spec records (value 0x01) received during the handshake.

  3. MUST use 0x0303 as the legacy_version in ServerHello.

These invariants ensure that TLS 1.3 traffic looks sufficiently like TLS 1.2 to middleboxes that do not understand the new protocol version, thereby maximizing deployment success.

Last updated on