[saag] A short-lived WG for HPKE

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]