Hybrid key exchange in TLS 1.3
draft-ietf-tls-hybrid-design-16

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, caw@heapingbits.net, draft-ietf-tls-hybrid-design@ietf.org, durumcrustulum@gmail.com, joe@salowey.net, paul.wouters@aiven.io, rfc-editor@rfc-editor.org, tls-chairs@ietf.org, tls@ietf.org
Subject: Document Action: 'Hybrid key exchange in TLS 1.3' to Informational RFC (draft-ietf-tls-hybrid-design-16.txt)

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/

Ballot Text

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.

RFC Editor Note