Skip to main content

HPKE Publication, Kept Efficient
charter-ietf-hpke-01

WG review announcement

WG Review Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: hpke@ietf.org 
Reply-To: iesg@ietf.org
Subject: WG Review: HPKE Publication, Kept Efficient (hpke)

A new IETF WG has been proposed in the Security Area. The IESG has not made
any determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to the
IESG mailing list (iesg@ietf.org) by 2025-05-05.

HPKE Publication, Kept Efficient (hpke)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
  Martin Thomson <mt@lowentropy.net>
  Yaroslav Rosomakho <yaroslavros@gmail.com>

Assigned Area Director:
  Deb Cooley <debcooley1@gmail.com>

Security Area Directors:
  Paul Wouters <paul.wouters@aiven.io>
  Deb Cooley <debcooley1@gmail.com>

Mailing list:
  Address: hpke@ietf.org
  To subscribe: https://mailman3.ietf.org/mailman3/lists/hpke.ietf.org/
  Archive: https://mailarchive.ietf.org/arch/browse/hpke

Group page: https://datatracker.ietf.org/group/hpke/

Charter: https://datatracker.ietf.org/doc/charter-ietf-hpke/

Hybrid Public Key Exchange (HPKE) [RFC 9180] defines an authenticated
encryption encapsulation format that combines a semi-static asymmetric key
exchange with a symmetric cipher. This format is used in several IETF
protocols, such as MLS [RFC 9420] and TLS Encrypted ClientHello
[draft-ietf-tls-esni]. The fact that HPKE is defined in an Informational
document on the IRTF stream, however, has caused some confusion as to its
usability, especially with other standards organizations. Also, there are
currently no “post-quantum” (PQ) Key Encapsulation Mechanisms (KEMs) defined
for HPKE, in the sense of algorithms that are resilient to attack by a
quantum computer.

The hpke Working Group is tasked with two responsibilities:

   1. Re-publish the HPKE specification as a Standards Track document of the
   IETF, with targeted changes based on experience with its use:
       * The working group may decide to apply any validated errata filed on
       RFC 9180 (Verified or Hold for Document Update). * The working group
       may decide to remove functionality that is not widely used. * The
       working group may define how Key Derivation Functions (KDFs) that are
       not two-step might be used with HPKE.

   2. Define PQ algorithms for HPKE from among the following:
       * New KEMs based on hybrid combinations of ML-KEM and ECDH (ML-KEM-768
       with X25519, ML-KEM-768 with P-256, and ML-KEM-1024 with P-384) and
       standalone ML-KEM (ML-KEM-768 and ML-KEM-1024). * New KDFs
       incorporating SHA3

Differences between the Standards Track version of HPKE and the Informational
version (RFC9180) documents should be minimized, in order to minimize impact
on existing deployments. The Standards Track and Informational versions must
have identical behavior for any functionality that they both specify.

The group might select a number of cipher suites that address different use
cases, security levels, and attacker threat models.

Milestones:

  Jun 2025 - HPKE specification to the IESG as Proposed Standard

  Jul 2025 - New post-quantum and post-quantum/traditional hybrid cipher
  suites for HPKE to the IESG as Proposed Standard


WG action announcement

WG Action Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>,
    hpke-chairs@ietf.org,
    hpke@ietf.org 
Subject: WG Action: Formed HPKE Publication, Kept Efficient (hpke)

A new IETF WG has been formed in the Security Area. For additional
information, please contact the Area Directors or the WG Chairs.

HPKE Publication, Kept Efficient (hpke)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
  Martin Thomson <mt@lowentropy.net>
  Yaroslav Rosomakho <yaroslavros@gmail.com>

Assigned Area Director:
  Deb Cooley <debcooley1@gmail.com>

Security Area Directors:
  Paul Wouters <paul.wouters@aiven.io>
  Deb Cooley <debcooley1@gmail.com>

Mailing list:
  Address: hpke@ietf.org
  To subscribe: https://mailman3.ietf.org/mailman3/lists/hpke.ietf.org/
  Archive: https://mailarchive.ietf.org/arch/browse/hpke

Group page: https://datatracker.ietf.org/group/hpke/

Charter: https://datatracker.ietf.org/doc/charter-ietf-hpke/

Hybrid Public Key Exchange (HPKE) [RFC 9180] defines an authenticated
encryption encapsulation format that combines a semi-static asymmetric key
exchange with a symmetric cipher. This format is used in several IETF
protocols, such as MLS [RFC 9420] and TLS Encrypted ClientHello
[draft-ietf-tls-esni]. The fact that HPKE is defined in an Informational
document on the IRTF stream, however, has caused some confusion as to its
usability, especially with other standards organizations. Also, there are
currently no “post-quantum” (PQ) Key Encapsulation Mechanisms (KEMs) defined
for HPKE, in the sense of algorithms that are resilient to attack by a
quantum computer.

The hpke Working Group is tasked with two responsibilities:

   1. Re-publish the HPKE specification as a Standards Track document of the
   IETF, with targeted changes based on experience with its use:
       * The working group may decide to apply any validated errata filed on
       RFC 9180 (Verified or Hold for Document Update). * The working group
       may decide to remove functionality that is not widely used. * The
       working group may define how Key Derivation Functions (KDFs) that are
       not two-step might be used with HPKE.

   2. Define PQ algorithms for HPKE from among the following:
       * New KEMs based on hybrid combinations of ML-KEM and ECDH (ML-KEM-768
       with X25519, ML-KEM-768 with P-256, and ML-KEM-1024 with P-384) and
       standalone ML-KEM (ML-KEM-768 and ML-KEM-1024). * New KDFs
       incorporating SHA3

Differences between the Standards Track version of HPKE and the Informational
version (RFC9180) documents should be minimized, in order to minimize impact
on existing deployments. The Standards Track and Informational versions must
have identical behavior for any functionality that they both specify.

The group might select a number of cipher suites that address different use
cases, security levels, and attacker threat models.

Milestones:

  Jun 2025 - HPKE specification to the IESG as Proposed Standard

  Jul 2025 - New post-quantum and post-quantum/traditional hybrid cipher
  suites for HPKE to the IESG as Proposed Standard


Ballot announcement

Ballot Announcement