]> Fastly Inc.

fde@00f.net

Individual Contributor

specifications@samuellucas.com

Transport Layer Security ciphersuite aegis tls dtls quic This document proposes new cipher suites based on the AEGIS family of authenticated encryption with associated data (AEAD) algorithms. The suites integrate AEGIS into TLS 1.3, DTLS 1.3, and QUIC. About This Document Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction and Rationale AEGIS is a family of authenticated encryption algorithms designed for high-performance applications. AEGIS targets the same hardware class as AES-GCM, distinguishing itself through the following key attributes:

1. Reduced memory requirements: AEGIS eliminates the need for a key schedule and precomputation tables, resulting in lower memory demands. This characteristic is particularly advantageous for servers managing a large number of connections.
2. Extended usage limits: AEGIS features higher usage limits, reducing the need for frequent rekeying compared to other available options.
3. Enhanced overall performance: AEGIS is highly efficient on CPUs supporting AES-specific instructions.

AEGIS ciphers integrate seamlessly into established protocols like TLS 1.3 by adhering to the same interface standards as existing algorithms. This document introduces new cipher suites based on the AEGIS algorithms and outlines the procedures for their incorporation into the TLS 1.3 , DTLS 1.3 , and QUIC protocols.

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 and Preservation of TLS 1.3 Mechanisms The TLS 1.3 protocol includes a set of mandatory cipher suites listed in . Each cipher suite specifies an authenticated encryption with associated data (AEAD) algorithm for record protection. It also specifies a hash algorithm for use with the HMAC-based key derivation function (HKDF). 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 additional cipher suites to accommodate AEGIS-based encryption algorithms: Proposed AEGIS-Based Cipher Suites

Cipher Suite Name	AEAD Algorithm	Hash Algorithm	Confidentiality Level
TLS_AEGIS_128L_SHA256	AEGIS-128L	SHA256	128 bits
TLS_AEGIS_128X2_SHA256	AEGIS-128X2	SHA256	128 bits
TLS_AEGIS_128X4_SHA256	AEGIS-128X4	SHA256	128 bits
TLS_AEGIS_256_SHA512	AEGIS-256	SHA512	256 bits
TLS_AEGIS_256X2_SHA512	AEGIS-256X2	SHA512	256 bits
TLS_AEGIS_256X4_SHA512	AEGIS-256X4	SHA512	256 bits

The rationale for recommending the SHA512 hash function for variants employing a 256-bit key is based on the findings presented in . AEGIS algorithms support both 128-bit and 256-bit authentication tags. For all the cipher suites specified herein, these algorithms MUST be used with a 128-bit authentication tag. 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 .

DTLS 1.3 Record Number Encryption In DTLS 1.3, encryption of record sequence numbers follows the specification detailed in . For AEGIS-based cipher suites, the mask is generated using the AEGIS Stream and ZeroPad functions defined in with:

• a 128-bit tag length
• sn_key, as defined in
• ciphertext[0..16]: the first 16 bytes of the DTLS ciphertext
• nonce_len: the AEGIS nonce length, either 128 or 256 bits, depending on the selected AEAD algorithm.

A 48-bit mask is computed as follows:

QUIC Header Protection In QUIC, specific segments of the packet header are protected as specified in . For AEGIS-based cipher suites, the mask is generated using the same procedure as in DTLS 1.3, with:

• a 128-bit tag length
• hp_key, as defined in
• ciphertext[0..16]: the first 16 bytes of the ciphertext
• nonce_len: the AEGIS nonce length, either 128 or 256 bits, depending on the selected AEAD algorithm.

A 5-byte (40-bit) mask is computed as follows:

Operational Considerations On devices lacking hardware AES acceleration or protection against side-channel attacks, cipher suites dependent on the AES round function SHOULD NOT be prioritized. This recommendation includes the cipher suites outlined in this document. On devices equipped with secure hardware AES acceleration, implementations SHOULD prioritize AEGIS-based cipher suites over AES-GCM cipher suites of equivalent security levels.

Implementation Status This note is to be removed before publishing as an RFC. A list of early implementations can be found at the project repository.

Security Considerations A key update MUST be performed before encrypting 2⁴⁸ records with the same key. The prescribed mechanism is documented in .

IANA Considerations IANA has registered the following identifiers in the TLS Cipher Suite Registry: Assigned IANA Identifiers

Value	Description	DTLS-OK	Recommended
0x13,0x06	TLS_AEGIS_256_SHA512	Y	N
0x13,0x07	TLS_AEGIS_128L_SHA256	Y	N

Implementations MAY use the following identifiers reserved for local testing: Additional Identifiers

Test Value	Description	DTLS-OK	Recommended
0xff01	TLS_AEGIS_128X2_SHA256	Y	N
0xff02	TLS_AEGIS_256X2_SHA512	Y	N
0xff03	TLS_AEGIS_128X4_SHA256	Y	N
0xff04	TLS_AEGIS_256X4_SHA512	Y	N

IANA is requested to assign the final identifiers.

References Normative References 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. Informative References Ericsson Research Cryptology ePrint Archive, Paper 2023/913 Fastly Inc. Individual Contributor This document describes the AEGIS-128L, AEGIS-256, AEGIS-128X, and AEGIS-256X AES-based authenticated encryption algorithms designed for high-performance applications. The document is a product of the Crypto Forum Research Group (CFRG). It is not an IETF product and is not a standard. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/cfrg/draft-irtf-cfrg-aegis-aead.

Examples

TLS 1.3 Handshake

With TLS_AEGIS_128L_SHA256

With TLS_AEGIS_256_SHA512

DTLS 1.3 and QUIC Header Protection Mask

With TLS_AEGIS_128L_SHA256

With TLS_AEGIS_128X2_SHA256

With TLS_AEGIS_256_SHA512

With TLS_AEGIS_256X2_SHA512

Acknowledgments We would like to thank John Preuß Mattsson for suggesting how AEGIS should be used in the context of DTLS and QUIC.