[saag] Re: A short-lived WG for HPKE

This is a fantastic and very well timed proposal — thanks for putting it together! I am strongly supportive of such a working group. The initial charter text seems like a fine place to start.

Best,
Chris 

> On 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]