Summary

  • The IESG approved the HPKE successor draft for publication as a Proposed Standard on 2 November; it specifies a one-stage key-derivation route alongside the established two-stage route.
  • Revision 06 says the cited HPKE security proofs cover two-stage KDFs. Their extension to one-stage KDFs has not been formally verified.

The gate opened, and the proof boundary came through with it. In its 2 November protocol action, the Internet Engineering Steering Group approved draft-ietf-hpke-hpke-06 for publication as a Proposed Standard. The Datatracker records “Approved-announcement sent.” An RFC number and the final RFC Editor text are later receipts. The immediate decision is that the IESG accepted a core HPKE specification with two ways to derive its working keys.

One route uses the familiar two-stage Extract() and Expand() construction. The other makes a single Derive() call over encoded inputs, with HPKE-specific labels and suite identifiers. This is a real protocol choice, not a typesetting shortcut: revision 06 gives separate pseudocode for the key schedule, KEM and exporter. The one-stage route was already present in revision 05. The new revision makes its evidentiary boundary harder to miss.

Section 1.1 now says the cited HPKE analyses cover the two-stage construction and have not studied the one-stage route in the same detail. Section 9.1 is sharper: the expected transfer of that analysis to a suitable one-stage KDF “has not been formally verified.” Section 9.3 states the condition a one-stage Derive() must meet: the key schedule stays pseudorandom if either the KEM shared secret or the pre-shared key remains unknown to an adversary, even when the other inputs are known or chosen. A random-oracle model for an extendable-output function such as SHAKE supplies the draft’s rationale. It is a stated rationale, not the missing formal extension.

The identifiers are already on a different clock. IANA’s HPKE registry lists SHAKE128, SHAKE256, TurboSHAKE128 and TurboSHAKE256 under codes 0x0010 through 0x0013, citing the separate post-quantum HPKE working-group draft. That document still has I-D Exists status. Revision 06 instructs IANA to add a Two-Stage column marking those four entries N; the public registry inspected on 3 November still shows its older columns. An assigned code is a shared name, not an inventory of deployed cryptography or a completed proof.

The design also has concrete bounds. One-stage psk, psk_id and info fields are length-prefixed in two bytes, so each is limited to 65,535 bytes; a separate two-byte output encoding caps one-stage export length at the same number. Those limits are implementable checks. They do not answer the analysis question. No public implementation matrix in the IESG announcement establishes which application profiles have selected which route; that inventory would change the operational assessment.