Use of Galois Counter Mode with Strong Secure Tags (GCM-SST) in TLS, DTLS and QUIC
draft-westerlund-tls-gcm-sst-00

Transport Layer Security                                   M. Westerlund
Internet-Draft                                         J. Preuß Mattsson
Intended status: Standards Track                                Ericsson
Expires: 7 January 2027                                      6 July 2026

  Use of Galois Counter Mode with Strong Secure Tags (GCM-SST) in TLS,
                             DTLS and QUIC
                    draft-westerlund-tls-gcm-sst-00

Abstract

   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.

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/.

   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/.

Westerlund & Preuß MattssExpires 7 January 2027                 [Page 1]
Internet-Draft        GCM-SST in TLS, DTLS and QUIC            July 2026

   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 7 January 2027.

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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  New Cipher Suites . . . . . . . . . . . . . . . . . . . . . .   3
   4.  TLS 1.3 Record Payload Protection . . . . . . . . . . . . . .   4
   5.  DTLS 1.3 Record Number Encryption . . . . . . . . . . . . . .   5
     5.1.  AES-GCM-SST Cipher Suites . . . . . . . . . . . . . . . .   5
     5.2.  Rijndael-GCM-SST Cipher Suites  . . . . . . . . . . . . .   5
   6.  QUIC Header Protection  . . . . . . . . . . . . . . . . . . .   6
     6.1.  AES-GCM-SST Cipher Suites . . . . . . . . . . . . . . . .   6
     6.2.  Rijndael-GCM-SST Cipher Suites  . . . . . . . . . . . . .   6
   7.  Key Update and Usage Limits . . . . . . . . . . . . . . . . .   7
   8.  Operational Considerations  . . . . . . . . . . . . . . . . .   8
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   11. Normative References  . . . . . . . . . . . . . . . . . . . .   9
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

Westerlund & Preuß MattssExpires 7 January 2027                 [Page 2]
Internet-Draft        GCM-SST in TLS, DTLS and QUIC            July 2026

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:

Westerlund & Preuß MattssExpires 7 January 2027                 [Page 3]
Internet-Draft        GCM-SST in TLS, DTLS and QUIC            July 2026

   +==============================+========================+=========+======+
   |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.

Westerlund & Preuß MattssExpires 7 January 2027                 [Page 4]
Internet-Draft        GCM-SST in TLS, DTLS and QUIC            July 2026

   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, 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:

Westerlund & Preuß MattssExpires 7 January 2027                 [Page 5]
Internet-Draft        GCM-SST in TLS, DTLS and QUIC            July 2026

   *  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 = Stream(16, sn_key, ZeroPad(ciphertext[0..15], 28))

   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
   [I-D.draft-mattsson-cfrg-aes-gcm-sst]), 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 [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, 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:

Westerlund & Preuß MattssExpires 7 January 2027                 [Page 6]
Internet-Draft        GCM-SST in TLS, DTLS and QUIC            July 2026

   *  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 = Stream(40, hp_key, ZeroPad(sample, 28))[0..4]

   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
   [I-D.draft-mattsson-cfrg-aes-gcm-sst]), and ZeroPad(x, len) right-
   pads the byte string x with zeros to a length of len bytes.

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.  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
   [I-D.draft-mattsson-cfrg-aes-gcm-sst].

   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 [I-D.draft-mattsson-cfrg-aes-gcm-sst]).  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.

Westerlund & Preuß MattssExpires 7 January 2027                 [Page 7]
Internet-Draft        GCM-SST in TLS, DTLS and QUIC            July 2026

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.

   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.

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.

Westerlund & Preuß MattssExpires 7 January 2027                 [Page 8]
Internet-Draft        GCM-SST in TLS, DTLS and QUIC            July 2026

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-
              21, 5 July 2026, <https://datatracker.ietf.org/doc/html/
              draft-mattsson-cfrg-aes-gcm-sst-21>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

Westerlund & Preuß MattssExpires 7 January 2027                 [Page 9]
Internet-Draft        GCM-SST in TLS, DTLS and QUIC            July 2026

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

   [RFC9001]  Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
              QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
              <https://www.rfc-editor.org/info/rfc9001>.

   [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,
              <https://www.rfc-editor.org/info/rfc9147>.

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

Westerlund & Preuß MattssExpires 7 January 2027                [Page 10]