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

We could do, but honestly, I don't think it'll to be a problem.  Among MLS
implementations alone, I think there are at least two who are chomping at
the bit to do PQ HPKE.

--Richard

On Wed, Mar 19, 2025 at 5:53 PM Stephen Farrell <[email protected]>
wrote:

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