[saag] A short-lived WG for HPKE

Hi Richard and Martin,

Thank you for putting together a thoughtful and focused proposal. Speaking
as CFRG co-chair, I don’t see any conflict between this proposed WG and the
CFRG.

Having a group like this solves a difficult problem for us: figuring out
how to do maintenance and updates on RFC 9280 as an IRTF research group
when the research questions around HPKE are effectively solved.

Specifying HPKE codepoints based on PQ and Hybrid KEMs also seems
unproblematic. This is tricky work, but the CFRG is working on a document
to provide sensible advice to anyone who wants to safely combine KEMs (
https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hybrid-kems-03). It
would be mutually beneficial to continue developing this document in
coordination with any work that goes on in this HPKE group in this area.
Doing so should help improve the group’s confidence in any concrete
constructions it chooses to specify and improve our document’s usefulness
to the IETF.

Furthermore, the Crypto Panel (https://wiki.ietf.org/group/cfrg/CryptoPanel)
can be made available to IETF groups looking for cryptographic advice. We’d
be happy to work with the chairs of this proposed group on developing a
streamlined process for providing concrete feedback on documents it
produces that have fully realized security considerations sections.

Nick
P.S. The CFRG has also been working on a document containing advice for
authors of cryptography specifications which could be useful to anyone
writing specifications within this group (https://datatracker.ietf.org/
doc/draft-irtf-cfrg-cryptography-specification/).

On Wed, Mar 19, 2025 at 4:53 PM Richard Barnes <[email protected]> wrote:

> Hello IETF security folks,
>
> At the CFRG session earlier this week, it became clear that the HPKE
> protocol is in need of some maintenance, so Martin Thomson and I wanted to
> propose a short-lived working group to make the required changes.
>
> HPKE (RFC 9180) documents a format that is widely used in IETF protocols.
> This was a product of the CFRG in the IRTF, so it is an Informational RFC.
>
> HPKE is basically sound, but we think that there are a few things we could
> to improve it:
>
> 1. Republish it as Proposed Standard.  It is already a recognized downref,
> so this is not about making it easier to cite, but we think that it would
> be worth having IETF consensus for it.
>
> 2. Fix errata.  There are enough (5 Verified, 2 HFDU, 1 Reported) to make
> it a good time to do that.
>
> 3. Add some PQ algorithms.  The MLS WG has identified a set of five KEM
> arrangements, both hybrid and pure PQ, that cover a wide array of use
> cases.  Unlike other protocols, HPKE is used in multiple places; the
> proposed charter suggests taking all five.  There may be some additional
> KDFs to define, if there is a desire to use SHA3 due to its presence in
> ML-KEM.
>
> We are also suggesting that maybe some adjustments are necessary, given
> experience with HPKE usage:
>
> * Removing the Auth and AuthPSK modes.  Our understanding is that these
> are not widely implemented or used, and they don’t appear to be supported
> by any post-quantum KEMs.
> * Making the changes necessary to add cipher suites with sponge form KDFs
> like SHA-3/SHAKE that don’t have discrete extract and expand phases.
>
> The goal would be to maintain 100% compatibility with existing usage,
> where the revised HPKE overlaps with that existing definition.  Obviously,
> removed features could continue to use RFC 9180 and new stuff would only be
> able to use the new definition.
>
> Proposed charter text follows.  Comments welcome!
>
> Thanks,
> --Richard and Martin
>
> ---
>
> HPKE Publication, Kept Efficient (hpke) Working Group Charter
>
> 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.  And there are
> currently no “post-quantum” (PQ) 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 errata filed on RFC 9180.
>     * The working group may decide to remove functionality that is not
> widely used (e.g., the Auth and AuthPSK modes).
>     * The working group may define how 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 based on SHA3
>
> Differences between the Standards Track version of HPKE and the
> Informational version (RFC9180) should be minimized. 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.
>
> Deliverables:
> 1. HPKE specification to the IESG as Proposed Standard (yesterday)
> 2. New post-quantum and post-quantum/traditional hybrid cipher suites for
> HPKE to the IESG as Proposed Standard (the day before that)
>
>
>
>
> _______________________________________________
> saag mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]