Document Action: 'Hybrid key exchange in TLS 1.3' to Informational RFC (draft-ietf-tls-hybrid-design-16.txt)

The IESG <iesg-secretary@ietf.org> Wed, 17 September 2025 21:46 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Document Action: 'Hybrid key exchange in TLS 1.3' to Informational RFC (draft-ietf-tls-hybrid-design-16.txt)
Auto-Submitted: auto-generated
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <175814558510.1963738.7521350415768457640@dt-datatracker-f7c8fdcb7-pjx77>
Date: Wed, 17 Sep 2025 14:46:25 -0700
Message-ID-Hash: 3KHSLDFLKFWGTKB7YRTXMUSAJHQ3PEUA
CC: The IESG <iesg@ietf.org>, draft-ietf-tls-hybrid-design@ietf.org, durumcrustulum@gmail.com, paul.wouters@aiven.io, rfc-editor@rfc-editor.org, tls-chairs@ietf.org, tls@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-announce/BjFYcZNLJ8Szo9klYOGPDfJrHx8>

The IESG has approved the following document:
- 'Hybrid key exchange in TLS 1.3'
  (draft-ietf-tls-hybrid-design-16.txt) as Informational RFC

This document is the product of the Transport Layer Security Working Group.

The IESG contact persons are Paul Wouters and Deb Cooley.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/




Technical Summary

   Hybrid key exchange refers to using multiple key exchange algorithms
   simultaneously and combining the result with the goal of providing
   security even if a way is found to defeat the encryption for all but
   one of the component algorithms. It is motivated by transition to
   post-quantum cryptography. This document provides a construction for
   hybrid key exchange in the Transport Layer Security (TLS) protocol
   version 1.3.

   
Working Group Summary

   Was there anything in the WG process that is worth noting?
   For example, was there controversy about particular points 
   or were there decisions where the consensus was
   particularly rough? 

Document Quality

   This draft has several implementations of hybrid groups that are based on
   the approach from this document already deployed. There is a decent chance you
   are using a hybrid group right now. Here is an incomplete list:

   Chrome, Mozilla, OpenSSL 3.5(To be released, currently supports when used with
   OQS), wolfSSL, AWS s2n, Cloudflare, Google, BoringSSL, rustTLS

   The cryptographic mechanisms used in this document are based the following:
   https://eprint.iacr.org/2018/903 (Section 3.2) which has been reviewed and
   published.

Personnel

   The Document Shepherd for this document is Joseph A. Salowey. The
   Responsible Area Director is Paul Wouters.

Document Action: 'Hybrid key exchange in TLS 1.3'… The IESG