]> Ericsson

magnus.westerlund@ericsson.com

Ericsson

john.mattsson@ericsson.com

Security Transport Layer Security TLS QUIC Cipher Suite GCM-SST This document defines cipher suites based on AES-GCM-SST and Rijndael-GCM-SST (Galois Counter Mode with Strong Secure Tags) for use in TLS 1.3, DTLS 1.3, and QUIC. GCM-SST provides authenticated encryption with near-ideal forgery probabilities for short authentication tags, making it suitable for bandwidth-constrained environments where reduced per-packet overhead is important. This document specifies cipher suites with 96-bit and 112-bit authentication tags. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Transport Layer Security Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction AES-GCM-SST and Rijndael-GCM-SST are Authenticated Encryption with Associated Data (AEAD) algorithms that provide near-ideal forgery probabilities even with short authentication tags. This makes them particularly suitable for use cases where bandwidth is constrained and reduced per-packet overhead is desirable, such as real-time media, IoT communications, and constrained radio networks. Standard AES-GCM with short tags has well-known weaknesses that significantly increase forgery probabilities, especially under multiple forgery attacks. GCM-SST addresses these weaknesses through the introduction of an additional subkey and per-nonce subkey derivation, following recommendations from Nyberg et al. Rijndael-GCM-SST uses Rijndael-256 (256-bit block size) as the keystream generator, providing a 28-byte nonce and significantly higher security margins against precomputation and multi-key attacks compared to AES-GCM-SST. This document specifies how AES-GCM-SST and Rijndael-GCM-SST algorithms are integrated into TLS 1.3 , DTLS 1.3 , and QUIC , defining new cipher suites and the necessary procedures for record number encryption and header protection.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

New Cipher Suites The cipher suites and cryptographic negotiation mechanisms established in TLS 1.3 are reused by the DTLS 1.3 and QUIC protocols. This document introduces the following cipher suites based on AES-GCM-SST: Cipher Suite Name AEAD Algorithm Hash Algorithm Tag Length (bits) TLS_AES_128_GCM_SST_12_SHA256 AEAD_AES_128_GCM_SST_12 SHA256 96 TLS_AES_128_GCM_SST_14_SHA256 AEAD_AES_128_GCM_SST_14 SHA256 112 TLS_AES_256_GCM_SST_12_SHA384 AEAD_AES_256_GCM_SST_12 SHA384 96 TLS_AES_256_GCM_SST_14_SHA384 AEAD_AES_256_GCM_SST_14 SHA384 112 TLS_RIJNDAEL_GCM_SST_12_SHA384 AEAD_RIJNDAEL_GCM_SST_12 SHA384 96 TLS_RIJNDAEL_GCM_SST_14_SHA384 AEAD_RIJNDAEL_GCM_SST_14 SHA384 112 The AEAD algorithms are defined in . The number in the cipher suite name after "SST" indicates the tag length in bytes (12 or 14). The 256-bit key variants (AES-256 and Rijndael) use SHA384 as the hash algorithm for HKDF to provide a security margin consistent with the larger key size. The Rijndael-GCM-SST variants use a 28-byte nonce, which provides significantly greater security against precomputation and multi-key attacks compared to the AES variants with their 12-byte nonce. With the inclusion of these new cipher suites, the cryptographic negotiation mechanism in TLS 1.3, as outlined in , remains unchanged, as does the record payload protection mechanism specified in .

TLS 1.3 Record Payload Protection When a GCM-SST cipher suite is negotiated, record payload protection follows using the negotiated AEAD algorithm. The per-record nonce is constructed as specified in : the 64-bit record sequence number is padded with leading zeros to the nonce length and XORed with the write_iv derived from the traffic secret. The nonce length is 12 bytes for AES-GCM-SST cipher suites and 28 bytes for Rijndael-GCM-SST cipher suites. The encrypted record has the following structure:

The tag_length is 12 or 14 bytes depending on the negotiated cipher suite.

DTLS 1.3 Record Number Encryption In DTLS 1.3, encryption of record sequence numbers follows the specification in .

AES-GCM-SST Cipher Suites For AES-GCM-SST cipher suites, the mask used for sequence number encryption is generated using AES-ECB with: sn_key: the sequence number encryption key as defined in ciphertext[0..15]: the first 16 bytes of the DTLS ciphertext The mask is computed as follows:

This is the same mechanism used for AES-GCM and AES-CCM cipher suites in DTLS 1.3.

Rijndael-GCM-SST Cipher Suites For Rijndael-GCM-SST cipher suites, Rijndael-256-ECB would require a 32-byte input, which may exceed the available ciphertext in short DTLS records. Instead, the mask is generated using the Rijndael-GCM-SST keystream generator with: sn_key: the sequence number encryption key as defined in ciphertext[0..15]: the first 16 bytes of the DTLS ciphertext The mask is computed as follows:

Where Stream(n, K, N) denotes the first n bits of keystream produced by the Rijndael-GCM-SST keystream generator instantiated with key K and nonce N (i.e., Rijndael-256 in counter mode as defined in ), and ZeroPad(x, len) right-pads the byte string x with zeros to a length of len bytes. The first 16 bits of the mask are used to encrypt the sequence number in the record header, following the procedure in .

QUIC Header Protection In QUIC, specific segments of the packet header are protected as specified in .

AES-GCM-SST Cipher Suites For AES-GCM-SST cipher suites, the header protection mask is generated using AES-ECB with: hp_key: the header protection key as defined in sample: a 16-byte sample from the packet payload ciphertext The 5-byte mask is computed as follows:

This is the same mechanism used for AES-GCM cipher suites in QUIC, as specified in .

Rijndael-GCM-SST Cipher Suites For Rijndael-GCM-SST cipher suites, Rijndael-256-ECB would require a 32-byte sample, which may exceed the available ciphertext in short QUIC packets. Instead, the mask is generated using the Rijndael-GCM-SST keystream generator with: hp_key: the header protection key as defined in sample: a 16-byte sample from the packet payload ciphertext The 5-byte mask is computed as follows:

Where Stream(n, K, N) denotes the first n bits of keystream produced by the Rijndael-GCM-SST keystream generator instantiated with key K and nonce N (i.e., Rijndael-256 in counter mode as defined in ), and ZeroPad(x, len) right-pads the byte string x with zeros to a length of len bytes.

Key Update and Usage Limits A key update MUST be performed prior to reaching the usage limits specified in . The key update mechanism is documented in . For AES-GCM-SST, the confidentiality and integrity limits depend on the specific AEAD instance. To ensure that the Bernstein bound factor satisfies delta approximately 1, protocols utilizing AES-GCM-SST MUST enforce that Q_MAX multiplied by P_MAX / 16 does not exceed approximately 2^59, as specified in . In TLS 1.3 and DTLS 1.3, where record payloads are limited to 2^14 bytes, the general constraint permits up to approximately 2^49 records per key for AES-GCM-SST cipher suites. In QUIC, where packet payloads can be up to 2^16 bytes, the constraint permits up to approximately 2^47 packets per key. Implementations MAY choose more conservative limits. The maximum number of failed decryption attempts (V_MAX) for AES-GCM-SST is 2^54. For Rijndael-GCM-SST cipher suites, the usage limits are significantly higher. A key update MUST be performed before encrypting 2^64 records with the same key (Q_MAX = 2^64 as specified in ). The maximum number of failed decryption attempts (V_MAX) for Rijndael-GCM-SST is 2^118. The number of failed decryption attempts (forgery attempts) before a key update or connection termination SHOULD be limited to V_MAX as specified above.

Operational Considerations The cipher suites defined in this document use 96-bit or 112-bit tags. For general-purpose use, cipher suites with 112-bit tags are RECOMMENDED. Rijndael-GCM-SST cipher suites offer significantly higher usage limits and stronger multi-key security compared to AES-GCM-SST, at the cost of requiring Rijndael-256 hardware support for optimal performance. On devices lacking hardware AES acceleration, cipher suites dependent on the AES round function SHOULD NOT be prioritized. On devices equipped with hardware AES acceleration, GCM-SST cipher suites provide performance comparable to standard AES-GCM cipher suites while offering improved integrity guarantees for a given tag length. To align with zero-trust principles and minimize the impact of key compromise, implementations SHOULD enforce rekeying well before reaching the cryptographic limits. Rekeying via ephemeral key exchange providing Forward Secrecy (FS) and Post-Compromise Security (PCS) after 1 hour or 2^30 to 2^37 bytes of data is RECOMMENDED.

Security Considerations The security properties of GCM-SST are detailed in . The key security advantages over standard AES-GCM with equivalent tag lengths are: Near-ideal forgery probability of approximately 1/2^tag_length, even for long messages. Resistance to multiple forgery attacks (reforgeability resistance). Per-nonce subkey derivation prevents key recovery from successful forgeries. GCM-SST MUST be used in a nonce-respecting setting. Nonce reuse enables universal forgery. The nonce construction in TLS 1.3 (XOR of sequence number with per-key IV) satisfies this requirement. The 96-bit tag cipher suites provide a forgery probability of approximately 2^-96 per attempt, which is suitable for most applications. The 112-bit tag cipher suites provide an even higher security margin.

IANA Considerations IANA is requested to assign identifiers in the TLS Cipher Suite Registry for the following cipher suites: Value Description DTLS-OK Recommended TBD TLS_AES_128_GCM_SST_12_SHA256 Y N TBD TLS_AES_128_GCM_SST_14_SHA256 Y N TBD TLS_AES_256_GCM_SST_12_SHA384 Y N TBD TLS_AES_256_GCM_SST_14_SHA384 Y N TBD TLS_RIJNDAEL_GCM_SST_12_SHA384 Y N TBD TLS_RIJNDAEL_GCM_SST_14_SHA384 Y N

Amazon Web Services Ericsson Ericsson This document defines Galois Counter Mode with Strong Secure Tags (GCM-SST), an Authenticated Encryption with Associated Data (AEAD) algorithm that addresses several weaknesses of GCM. GCM-SST can be used with any keystream generator, not only 128-bit block ciphers. Main differences from GCM are the introduction of a second authentication subkey H_2, per-nonce derivation of both H and H_2, and stricter usage limits. Together, these changes yield authentication tags with near-ideal forgery probabilities, including reforgeability resistance. All registered instances have an expected number of forgeries E(F) ≈ v / 2^t, a property that GCM is far from providing. GCM-SST is designed for security protocols with replay protection such as TLS, QUIC, SRTP, and PDCP, and provides hardware and software performance comparable to GCM. This document registers nine AEAD algorithm instances using AES and Rijndael-256 in counter mode, with tag lengths of 48, 96, and 112 bits. GCM-SST has been standardized by 3GPP for use with SNOW 5G, AES-256, and ZUC-256. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes how Transport Layer Security (TLS) is used to secure QUIC.

Acknowledgments This document is based on draft-denis-tls-aegis. The authors would like to thank Frank Denis and Samuel Lucas for their work on that document.