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

Hi,

I think this sounds like a very good idea. Some comments on the proposed charter:

OLD: semi-static
NEW: static

RFC 9180 talks about static keys. I don’t think that there is anything stating that they are short-lived.

---

- “Re-publish the HPKE”
I think “Publish” might be better word given that there is quite a lot of potential changes.

---

- “Differences between the Standards Track version of HPKE and the Informational version (RFC9180) should be minimized.”
I think this could be removed. There are quite a lot of suggested changes, and I think clarifications and new security considerations should be in scope. The sentence “The Standards Track and Informational versions must have identical behavior for any functionality that they both specify.” clearly states where we do not want any differences.

---

OLD: “Define PQ algorithms for HPKE from among the following”
NEW: “Define algorithms for HPKE, for example

KDFs based on SHA3 are not typically called “PQ” even if they are PQ. I don’t have anything against the items in the list, but I am not sure that the charter should limit the the group to only define these combinations. I think the WG should update the already registered X-Wing, ML-KEM-1024, ML-KEM-768, ML-KEM-512 to point to a standard track RFC. I think it is good that the charter does not mention any specific KEM combiner. CFRG RFCs might not be ready in time, and I this is clearly something IETF can do anyway (likely with review from the CFRG crypto panel).

Cheers,
John


From: Nick Sullivan <[email protected]>
Date: Wednesday, 19 March 2025 at 17:38
To: Richard Barnes <[email protected]>
Cc: IETF SAAG <[email protected]>
Subject: [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]<mailto:[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]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>

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