Summary

  • On 26 September, the IESG issued an approval ballot for revision 05 of the HPKE successor draft and put it on the 8 October telechat agenda. It remains in IESG Evaluation; its proposal to obsolete RFC 9180 is conditional, not an accomplished standards change.
  • The draft defines Base and pre-shared-key modes but reserves the two values that RFC 9180 uses for Auth and AuthPSK. That omission was already in revision 04; it is not a newly deleted feature of revision 05.
  • Its IANA text retains the KEM registry's Auth field for RFC 9180 compatibility. An application relying on a sender's static key needs an explicit compatibility decision; the registry field alone does not prove that application has migrated.

The word “successor” can hide a boundary. In a standards index, a new document may replace the reference to an old one. In running software, the older document may still describe a function on which an application depends. The HPKE working group's latest draft places those two facts side by side as it reaches the IESG ballot. If approved and published, it would obsolete the 2022 HPKE RFC 9180. It does not claim to carry forward every interface in that RFC.

The distinction is concrete in the one-byte mode values. RFC 9180 defines Base at 0x00, PSK at 0x01, Auth at 0x02, and AuthPSK at 0x03. The proposed successor's Table 1 defines the first two and reserves the latter two. Its appendix says Auth and AuthPSK have been removed, while common behavior between the two specifications is intended to remain compatible. “Common” is doing important work: it is not a promise that a receiver configured for the old Auth mode will find an equivalent sender-key mode in the successor. Nor is the retained PSK mode the same assertion as authenticating possession of a sender's asymmetric private key.

This is not a surprise edit smuggled into revision 05. Revision 04 already showed the same mode table. The dated news is procedural: revision 05 arrived on 25 September, and the IESG issued its approval ballot, entered Evaluation and scheduled the 8 October telechat on the following day. The Datatracker still shows outstanding positions and IANA review required after the version change. The draft has not become an RFC, and RFC 9180 has not already been obsoleted by it.

The document shepherd makes the residual problem unusually plain. In a March write-up, Martin Thomson said the working group removed authenticated modes because deployment was limited and suitable post-quantum support did not yet fit the present design. He also said some people rely on those modes, characterising the omission as a deferral rather than a deprecation and leaving open later restoration. That is a qualitative account of the group's decision, not a census of products or a declaration that existing implementations are insecure.

The proposed registry treatment reinforces the difference between a reference change and a capability change. Section 11 would update IANA references while retaining existing KEM codepoints. Section 11.2 keeps an Auth Boolean in the KEM registration template precisely for RFC 9180's AuthEncap() and AuthDecap() interface, and says the new document does not use that field. A registration can therefore remain legible to older implementations even though the successor no longer specifies their Auth mode. It cannot tell an operator whether an application actually invokes that interface, how it negotiates modes, or which identity property a recipient expects.

The sensible unit of review is an application contract, not the word HPKE on a dependency list. For each integration that might use Auth or AuthPSK, the operator can identify the mode, the relevant RFC reference, the sender-identity assertion, the peer's accepted modes and the behavior demonstrated in tests. It may then choose to retain an RFC 9180-specific path, alter the surrounding protocol's authentication design, or wait for later standards work. Those are options to evaluate, not outcomes ordered by this draft. A library upgrade or IANA reference edit should not silently decide which sender claim a service makes.

Sources