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

Thanks for the edits, John.  Mostly agree, will get this reflected in the
next revision.

Re: Listing the new algorithms in the charter -- I think this is actually
an important constraint to have in the charter.  We're going to have to
make a decision as to which combinations to do, either now or in the WG,
and it seems better to go ahead and get it over with.  If there's a lot of
energy for more options, rechartering is possible.

On Wed, Mar 19, 2025 at 6:02 PM John Mattsson <[email protected]>
wrote:

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