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

 Of course, I mean RFC 9180, not RFC 9280.

On Wed, Mar 19, 2025 at 5:38 PM, Nick Sullivan <[email protected]>
wrote:

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