Transport Layer Security M. Westerlund Internet-Draft J. Preuß Mattsson Intended status: Standards Track Ericsson Expires: 19 November 2026 18 May 2026 Use of Galois Counter Mode with Secure Short Tags (GCM-SST) in TLS, DTLS and QUIC draft-westerlund-tls-gcm-sst-latest Abstract This document defines cipher suites based on AES-GCM-SST and Rijndael-GCM-SST (Galois Counter Mode with Secure Short 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. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://gloinul.github.io/draft-westerlund-tls-gsm-sst/draft- westerlund-tls-gsm-sst.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-westerlund- tls-gcm-sst/. Discussion of this document takes place on the Transport Layer Security Working Group mailing list (mailto:tls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tls/. Subscribe at https://www.ietf.org/mailman/listinfo/tls/. Source for this draft and an issue tracker can be found at https://github.com/gloinul/draft-westerlund-tls-gsm-sst. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted 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." This Internet-Draft will expire on 19 November 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 2. Conventions and Definitions 3. New Cipher Suites 4. TLS 1.3 Record Payload Protection 5. DTLS 1.3 Record Number Encryption 5.1. AES-GCM-SST Cipher Suites 5.2. Rijndael-GCM-SST Cipher Suites 6. QUIC Header Protection 6.1. AES-GCM-SST Cipher Suites 6.2. Rijndael-GCM-SST Cipher Suites 7. Key Update and Usage Limits 8. Operational Considerations 9. Security Considerations 10. IANA Considerations 11. Normative References Acknowledgments Authors' Addresses 1. Introduction AES-GCM-SST and Rijndael-GCM-SST [I-D.draft-mattsson-cfrg-aes-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 [RFC8446], DTLS 1.3 [RFC9147], and QUIC [RFC9000], defining new cipher suites and the necessary procedures for record number encryption and header protection. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. 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 |Tag | | | |Algorithm|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 | +------------------------------+------------------------+---------+------+ Table 1: GCM-SST cipher suites for TLS 1.3 The AEAD algorithms are defined in [I-D.draft-mattsson-cfrg-aes-gcm-sst]. 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 [RFC8446], Section 4.1.1, remains unchanged, as does the record payload protection mechanism specified in [RFC8446], Section 5.2. 4. TLS 1.3 Record Payload Protection When a GCM-SST cipher suite is negotiated, record payload protection follows [RFC8446], Section 5.2 using the negotiated AEAD algorithm. The per-record nonce is constructed as specified in [RFC8446], Section 5.3: 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: struct { opaque content[TLSPlaintext.length]; ContentType type; uint8 zeros[length_of_padding]; } TLSInnerPlaintext; struct { ContentType opaque_type = application_data; /* 23 */ ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */ uint16 length; opaque encrypted_record[TLSInnerPlaintext.length + tag_length]; } TLSCiphertext; The tag_length is 12 or 14 bytes depending on the negotiated cipher suite. 5. DTLS 1.3 Record Number Encryption In DTLS 1.3, encryption of record sequence numbers follows the specification in [RFC9147], Section 4.2.3. 5.1. 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 [RFC9147], Section 4.2.3 * ciphertext[0..15]: the first 16 bytes of the DTLS ciphertext The mask is computed as follows: mask = AES-ECB(sn_key, ciphertext[0..15]) This is the same mechanism used for AES-GCM and AES-CCM cipher suites in DTLS 1.3. 5.2. Rijndael-GCM-SST Cipher Suites For Rijndael-GCM-SST cipher suites, the mask is generated using Rijndael-256-ECB with: * sn_key: the sequence number encryption key as defined in [RFC9147], Section 4.2.3 * ciphertext[0..31]: the first 32 bytes of the DTLS ciphertext The mask is computed as follows: mask = Rijndael-256-ECB(sn_key, ciphertext[0..31]) The first 16 bits of the mask are used to encrypt the sequence number, following the procedure in [RFC9147], Section 4.2.3. 6. QUIC Header Protection In QUIC, specific segments of the packet header are protected as specified in [RFC9001], Section 5.4. 6.1. 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 [RFC9001], Section 5.4.3 * sample: a 16-byte sample from the packet payload ciphertext The 5-byte mask is computed as follows: mask = AES-ECB(hp_key, sample)[0..4] This is the same mechanism used for AES-GCM cipher suites in QUIC, as specified in [RFC9001], Section 5.4.3. 6.2. Rijndael-GCM-SST Cipher Suites For Rijndael-GCM-SST cipher suites, the header protection mask is generated using Rijndael-256-ECB with: * hp_key: the header protection key as defined in [RFC9001], Section 5.4.3 * sample: a 32-byte sample from the packet payload ciphertext The 5-byte mask is computed as follows: mask = Rijndael-256-ECB(hp_key, sample)[0..4] 7. Key Update and Usage Limits A key update MUST be performed prior to reaching the usage limits specified in [I-D.draft-mattsson-cfrg-aes-gcm-sst]. The key update mechanism is documented in [RFC8446], Section 4.6.3. For AES-GCM-SST, the confidentiality and integrity limits depend on the specific AEAD instance. Protocols utilizing AES-GCM-SST MUST ensure that (P_MAX + A_MAX) * (Q_MAX + V_MAX) does not exceed approximately 2^66, as specified in [I-D.draft-mattsson-cfrg-aes-gcm-sst]. In TLS 1.3 and QUIC, where record/packet payloads are limited to approximately 2^14 bytes, a key update MUST be performed before encrypting 2^32 records with the same key for AES-GCM-SST cipher suites. For Rijndael-GCM-SST cipher suites, the usage limits are significantly higher (Q_MAX = V_MAX = 2^88), and a key update MUST be performed before encrypting 2^88 records with the same key. The number of failed decryption attempts (forgery attempts) before a key update or connection termination SHOULD be limited. 8. 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. 9. Security Considerations The security properties of GCM-SST are detailed in [I-D.draft-mattsson-cfrg-aes-gcm-sst]. 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. 10. 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 | +-------+--------------------------------+---------+-------------+ Table 2: IANA cipher suite assignments 11. Normative References [I-D.draft-mattsson-cfrg-aes-gcm-sst] Campagna, M., Maximov, A., and J. P. Mattsson, "Galois Counter Mode with Strong Secure Tags (GCM-SST)", Work in Progress, Internet-Draft, draft-mattsson-cfrg-aes-gcm-sst- 18, 19 February 2025, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, . [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, . 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. Authors' Addresses Magnus Westerlund Ericsson Email: magnus.westerlund@ericsson.com John Preuß Mattsson Ericsson Email: john.mattsson@ericsson.com