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

Hiya,

I'm not sure about short-lived, but also support this and
the charter is a v. good starting point. The charter might
be improved by calling for 2 independent implementations
before any new suite spec is emitted from the WG (or for
some other indication that more than just one project is
interested).

Cheers,
S.

On 19/03/2025 09:52, Richard Barnes 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]

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQQwbnhHy1kPJkWsM6fk2On5l6gz3QUCZ9qiDwUDAAAAAAAKCRDk2On5l6gz3WNC
AP92VnEwP3WTcg8xdQDSTI+OcGnNWjWBwzSJnuSSX80bTAD+PCtRbSUQiv9rxNKEgFZtJnbmVSr6
dYhCYQGb3HKdUAA=
=qk+l
-----END PGP SIGNATURE-----