[secdir] [new-work] Re: WG Review: HPKE Publication, Kept Efficient (hpke)

[Deirdre Connolly <[e-mail]>]

I support this new working group and plan to participate, review documents,
and submit new documents.

On Fri, Apr 25, 2025, 12:05 PM The IESG <[e-mail]> wrote:

> 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 ([e-mail]) by 2025-05-05.
>
> HPKE Publication, Kept Efficient (hpke)
> -----------------------------------------------------------------------
> Current status: Proposed WG
>
> Chairs:
>   Martin Thomson <[e-mail]>
>   Yaroslav Rosomakho <[e-mail]>
>
> Assigned Area Director:
>   Deb Cooley <[e-mail]>
>
> Security Area Directors:
>   Paul Wouters <[e-mail]>
>   Deb Cooley <[e-mail]>
>
> Mailing list:
>   Address: [e-mail]
>   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
>
>
>
> _______________________________________________
> new-work mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> _______________________________________________
> secdir mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> wiki: https://wiki.ietf.org/group/secdir/SecDirReview

_______________________________________________
new-work mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]