Summary

  • draft-ietf-hpke-hpke-05, now in IESG Evaluation, proposes Base and PSK as the two HPKE modes and reserves 0x02 and 0x03, which RFC 9180 assigned to Auth and AuthPSK.
  • The text can define the next common specification. It cannot prove that every application profile, compiled library, configured service, stored object and counterparty has left the older compatibility set.

Four rows became two. RFC 9180 lists Base, PSK, Auth and AuthPSK. The current IETF replacement candidate keeps Base at 0x00, keeps PSK at 0x01, and marks the two values formerly used by Auth and AuthPSK as reserved.

That is a meaningful change. It narrows the proposed standards-track core and removes setup functions that combined a sender's static key with the recipient's key. It also creates a tempting but unsafe sentence for migration reports: “the modes were removed, so we no longer use them.”

The first half of that sentence is about a document. The second is about running systems. They require different evidence.

The current document is a candidate, not yet the new RFC

Datatracker records revision 05 as an active HPKE Working Group Internet-Draft, dated 26 September 2026. It is intended for Proposed Standard, submitted for publication, in IESG Evaluation and on the 8 October telechat agenda. The IANA review state still says that review is needed after a version change.

The header says the document would obsolete RFC 9180 if approved. The condition matters. Revision 05 is not yet an RFC, and the frozen record does not show a completed IESG decision or RFC publication.

The removal itself is not a revision-05 surprise. Revision 04 already carried the same two-mode table and the same major-difference note. The news is that this design has reached the current IESG-evaluation text, not that the September upload invented it.

RFC 9180 came from the IRTF stream as an Informational RFC. The replacement seeks IETF Proposed Standard status. That process can establish the next common contract. It does not rewrite the state of every program that implemented the earlier one.

Backward-compatible where both documents speak

Appendix A makes a careful promise. The draft is intended to be backward-compatible with RFC 9180 where both specifications define the same behavior. Base and PSK remain. Shared algorithms and inputs should produce the same results where the two texts overlap.

Auth and AuthPSK are outside that overlap. RFC 9180 assigns them 0x02 and 0x03; revision 05 reserves those values and says the variants were removed. Calling the whole transition “backward-compatible” without that qualifier conceals the one place where compatibility is deliberately not preserved.

It also conceals what compatibility means. A common test vector can show that two implementations derive the same result for one suite and one input. It cannot show that an application never calls an older API, that a vendored library has disappeared, or that a delayed object will never need an old receive path.

HPKE does not provide a universal inventory envelope

HPKE is a construction embedded by other protocols. The draft says the application transports non-private parameters such as enc and psk_id. If a recipient has several keys, the application must also provide a way to select the right recipient key. That mechanism is outside HPKE.

The mode and ciphersuite are part of the context chosen by the implementation. There is no single universal HPKE message format whose visible header can be scanned across every product to produce a complete mode census.

This makes the application profile the critical control surface. An operator needs to know which specification, API call, feature flag, object metadata or negotiation result selects a mode. A packet counter without that context may count ciphertexts while saying nothing reliable about the setup path. A source-code search may find SetupAuthS in a dependency that is never enabled. A clean source tree may miss a statically linked binary, hardware implementation or old worker image.

Retirement is therefore a join across records, not a grep result.

Removal does not mean rejection

The evidence states should be recorded separately.

A standards-state receipt identifies revision 05, its process state and the exact behavior it proposes to remove. A dependency receipt identifies the library and build actually loaded by a service. A configuration receipt says which modes are allowed for which operation and counterparty. A use receipt observes the application choice on an emitted or received operation. A peer receipt shows that the intended counterparty completed the replacement profile. An outcome receipt shows that the application action beyond decryption succeeded.

None can stand in for all the others. Removing an API from a new release does not prove every deployed instance upgraded. Installing the release does not prove a stale process restarted. Restarting does not prove a tenant exception is closed. Closing exceptions does not prove an archive contains no old objects. A successful Base or PSK canary does not prove every peer and delayed-message path is ready.

The reverse is also true. Finding an old symbol proves capability, not use. Finding a configured exception proves permission, not an emitted message. Successfully opening a legacy object proves decryption, not business authorization or a successful downstream action.

The extension proposal is evidence of a separate compatibility set

An active individual Internet-Draft, draft-ms-hpke-auth-modes-01, proposes restoring AuthPSK as a strict extension. It reintroduces the Auth mechanics as a building block but declines to restore standalone Auth, arguing that Auth alone cannot supply quantum-resistant encryption.

Datatracker places an explicit boundary around that document: anyone may submit an individual draft; it is not endorsed by the IETF and has no formal standing in the standards process. It is not an approved escape hatch.

It is still useful evidence. It shows that “removed from the proposed core” and “technically impossible to specify elsewhere” are different claims. The proposed extension would create another compatibility set, with its own setup functions, security analysis, application bindings and adoption decisions.

Mailing-list discussion makes the design disagreement visible. Participants debate whether to preserve classical implicit authentication, how signatures would fit, and whether authenticated behavior should be separated from a post-quantum construction. Those messages document views, not consensus or deployment. They reinforce the need to label each receipt with its authority.

PSK possession is not an organizational identity

The current core still has a sender-authentication property in PSK mode. Its table says PSK can prove sender origin under the construction because both sides possess the pre-shared key.

That is not a licence to promote every successful PSK operation into proof of one named person, service or legal entity. A PSK may be shared by several processes or counterparties. Its distribution, scope, rotation and binding to an application identity are external controls. Compromise or reuse changes what possession means.

The draft also lists important non-goals. HPKE itself does not solve application replay, downgrade, message order or loss; it does not hide plaintext length; it does not provide forward secrecy against later compromise of the recipient private key; and it does not cure bad ephemeral randomness. A successful context setup or decryption must remain separate from freshness, authorization and outcome.

This distinction prevents the migration from replacing one overclaim with another. Moving from Auth to PSK is not complete merely because a test ciphertext opens. The operator must show that the new peer binding and key-distribution model carries the authority the application actually needs.

Stored objects can outlive the send path

Teams often audit the live sender first. That is necessary and incomplete. An application may keep encrypted mail, telemetry bundles, delayed jobs, retry queues, backups or legal archives longer than it keeps the binary that created them.

Disabling an old receive path before inventorying durable data can convert a standards migration into a data-availability incident. Keeping the path forever without isolation can turn a temporary compatibility exception into an unowned security surface.

The retirement ledger should therefore record stored-object format, creation window, selected profile, key identifier, retention horizon and the last successful replacement read. Where the application did not store enough metadata to identify the old mode safely, that uncertainty is a finding. Guessing from ciphertext shape is not a control.

Publication defines a target; observation proves the cutover

Heng Lu's Minimum Initial Specification and Running-Code Primacy provide a useful analytical lens. A document can define a common rule. Later change becomes real for a participant through implementation, validation, deployment and use. Non-adoption does not magically erase a participant; it leaves a different compatibility set.

Applied here, the conclusion is neither that the IETF draft is powerless nor that publication instantly changes reality. The draft can legitimately define a smaller core. Operators then decide how to join it without mistaking documentation for execution.

A credible closure statement is bounded: which profiles were inventoried; which builds were measured; which configuration paths were disabled; which stored objects were migrated or given a documented exception; which peers passed replacement tests; and for how long no old path was observed. Anything broader should remain unknown.

Sources