Network Working Group G. Berra, Ed. Internet-Draft C. F. Myers, Ed. Intended status: Standards Track R. Shane, Ed. Expires: 16 November 2026 Freedom of the Press Foundation 15 May 2026 Authenticated Modes for HPKE draft-ms-hpke-auth-modes-01 Abstract The standards-track [I-D.ietf-hpke-hpke] supersedes the informational [RFC9180], omitting its authenticated modes mode_auth and mode_auth_psk. This document restores mode_auth_psk mode as a strict extension and illustrates how the restored mode can be used with a post-quantum "shared secret" as the PSK in order to achieve hybrid PQ/T confidentiality while transitioning to quantum-resistant encryption, without deprecating the classical implicit authentication on which many applications still rely. This extension requires only the addition of AuthEncap()/AuthDecap() to the DHKEM, the definition of four setup functions, and a change in VerifyPSKInputs(). The extension does not alter the externally observable behavior of the existing HPKE modes standardized in [I-D.ietf-hpke-hpke]. Although AuthEncap()/AuthDecap() reintroduce the functionality of mode_auth, the mode itself is not restored, since it cannot provide quantum resistance. This document discusses the transitional nature of the AuthPSK construction and its security properties as a transitional step towards quantum resistance. In particular, this document illustrates how the restored mode_auth_psk can be used to provide ready-made KEM combiner-like functionality ([I-D.ounsworth-cfrg-kem-combiners]) without requiring downstream API users to manage their own encryption context. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ms-hpke-auth-modes/. Source for this draft and an issue tracker can be found at https://github.com/cfm/draft-ms-hpke-auth-modes. Berra, et al. Expires 16 November 2026 [Page 1] Internet-Draft HPKE Authenticated Modes May 2026 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 16 November 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Authenticated Pre-Shared Key Mode Extension to I-D.ietf-hpke-hpke . . . . . . . . . . . . . . . . . . . 4 3.1. Mode Identifiers . . . . . . . . . . . . . . . . . . . . 4 3.2. Exclusion of 0x02 mode_auth from Mode Identifiers . . . . 4 3.3. DHKEM Extension: AuthEncap() and AuthDecap() . . . . . . 4 3.4. VerifyPSKInputs . . . . . . . . . . . . . . . . . . . . . 5 3.5. Setup Functions . . . . . . . . . . . . . . . . . . . . . 6 3.6. Input Validation and Error Handling . . . . . . . . . . . 6 3.7. DHAKEM with PSK . . . . . . . . . . . . . . . . . . . . . 6 3.7.1. PQ/T Hybrid Construction . . . . . . . . . . . . . . 6 3.7.2. AKEM/PQ KEM "Combiner" (Informative) . . . . . . . . 7 3.8. Motivation (Informative) . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 Berra, et al. Expires 16 November 2026 [Page 2] Internet-Draft HPKE Authenticated Modes May 2026 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction [I-D.ietf-hpke-hpke] is the standards-track successor to the informational [RFC9180] and omits the authenticated modes mode_auth and mode_auth_psk to simplify the standard. However, some applications make use of the type of implicit sender authentication provided by these modes. The normative portion of this document is small. It restores mode_auth_psk as a strict extension to [I-D.ietf-hpke-hpke]. This requires AuthEncap()/AuthDecap() from the DHKEM construction in [RFC9180], and a modified VerifyPSKInputs(). The externally observable behavior of existing HPKE modes is unchanged. AuthEncap() computes a static-static DH value DH(skS, pkR) alongside the ephemeral-static value and mixes both into the key derivation, binding the output to the sender's key pair. Although the functionality of mode_auth is re-introduced, the mode identifer itself, which relies solely on DHKEM, is not restored, since it cannot provide quantum-resistant encryption. mode_auth is instead treated as a building block to mode_auth_psk, as seen in Section 3.7. Section 3.3 describes how the restored mode_auth_psk can be used to achieve hybrid PQ/T confidentiality as defined in Section 5 of [RFC9794] during the transition to quantum-resistant encryption. Section 3.8 discusses the transitional nature of this construction and reviews the guidance available to application developers looking to begin the transition to quantum-resistant encryption with existing libraries and APIs. To motivate the extension, Section 3.7.2 discusses how the extension can be used as a type of black-box KEM combiner ([I-D.ounsworth-cfrg-kem-combiners]), similar to the construction proposed in [Alwen2023], to allow application developers to begin the transition to quantum-resistant encryption via usable libraries and APIs. Berra, et al. Expires 16 November 2026 [Page 3] Internet-Draft HPKE Authenticated Modes May 2026 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Terms from [I-D.ietf-hpke-hpke] are used without redefinition; particular reference is made to the *DHKEM* construction Section 4.1 of [RFC9180]. The following additional term is used herein: * *AKEM:* a KEM whose encapsulation additionally takes the sender's static private key and implicitly binds the shared secret to it. 3. Authenticated Pre-Shared Key Mode Extension to [I-D.ietf-hpke-hpke] This section specifies the additions to [I-D.ietf-hpke-hpke] required to restore mode_auth_psk. These extensions are defined so that the externally observable behavior of the existing HPKE modes is unchanged, although this document modifies the VerifyPSKInputs() procedure in [I-D.ietf-hpke-hpke]. 3.1. Mode Identifiers The reserved entry for value 0x03 in Table 1 of [I-D.ietf-hpke-hpke] is replaced with the following mode identifier, as originally specified in Table 1 of [RFC9180]: mode_auth_psk = 0x03 The value 0x02 remains reserved. 3.2. Exclusion of 0x02 mode_auth from Mode Identifiers Although restoring the AuthEncap() and AuthDecap() functions would also allow for restoring mode_auth, this mode cannot offer quantum- resistant encryption, and its identifier is therefore not reintroduced. 3.3. DHKEM Extension: AuthEncap() and AuthDecap() The following two functions are added to the DHKEM, extending it to an AKEM (DHAKEM). They are reproduced verbatim from Section 4.1 of [RFC9180]. All helper functions (GenerateKeyPair, DH, SerializePublicKey, DeserializePublicKey, ExtractAndExpand) are as defined in [I-D.ietf-hpke-hpke]. Berra, et al. Expires 16 November 2026 [Page 4] Internet-Draft HPKE Authenticated Modes May 2026 def AuthEncap(pkR, skS): skE, pkE = GenerateKeyPair() dh = concat(DH(skE, pkR), DH(skS, pkR)) enc = SerializePublicKey(pkE) pkRm = SerializePublicKey(pkR) pkSm = SerializePublicKey(pk(skS)) kem_context = concat(enc, pkRm, pkSm) shared_secret = ExtractAndExpand(dh, kem_context) return shared_secret, enc def AuthDecap(enc, skR, pkS): pkE = DeserializePublicKey(enc) dh = concat(DH(skR, pkE), DH(skR, pkS)) pkRm = SerializePublicKey(pk(skR)) pkSm = SerializePublicKey(pkS) kem_context = concat(enc, pkRm, pkSm) shared_secret = ExtractAndExpand(dh, kem_context) return shared_secret Note that the AuthEncap() and AuthDecap() functions are vulnerable to key-compromise impersonation (KCI): the assurance that the shared secret was generated by the holder of the private key skS does not hold if the recipient private key skR is compromised. See Section 4 for further discussion; see Section 3.5 for integration of a pre- shared key. 3.4. VerifyPSKInputs The VerifyPSKInputs() function defined in Section 5.1 of [RFC9180] and [I-D.ietf-hpke-hpke] is extended to handle the reintroduced mode_auth_psk. The updated function replaces the original: def VerifyPSKInputs(mode, psk, psk_id): got_psk = (psk != default_psk) got_psk_id = (psk_id != default_psk_id) if got_psk != got_psk_id: raise Exception("Inconsistent PSK inputs") if got_psk and mode in [mode_base]: raise Exception("PSK input provided when not needed") if (not got_psk) and mode in [mode_psk, mode_auth_psk]: raise Exception("Missing required PSK input") Berra, et al. Expires 16 November 2026 [Page 5] Internet-Draft HPKE Authenticated Modes May 2026 The only change from the original is that mode_psk is replaced by [mode_psk, mode_auth_psk] in the final guard. 3.5. Setup Functions The following four setup functions are reproduced verbatim from Sections 5.1.3 and 5.1.4 of [RFC9180]. KeyScheduleS()/KeyScheduleR() and AuthEncap()/AuthDecap() are as defined in [I-D.ietf-hpke-hpke] and Section 3.3 respectively. def SetupAuthPSKS(pkR, info, psk, psk_id, skS): shared_secret, enc = AuthEncap(pkR, skS) return enc, KeyScheduleS(mode_auth_psk, shared_secret, info, psk, psk_id) def SetupAuthPSKR(enc, skR, info, psk, psk_id, pkS): shared_secret = AuthDecap(enc, skR, pkS) return KeyScheduleR(mode_auth_psk, shared_secret, info, psk, psk_id) 3.6. Input Validation and Error Handling In addition to the validation requirements in Section 7.1.4 of [I-D.ietf-hpke-hpke], the recipient MUST validate the sender's static public key pkS before use in AuthDecap(), applying the same validation rules as for other public key inputs. Validation failure MUST yield a ValidationError. 3.7. DHAKEM with PSK This section illustrates how the authenticated mode defined in Section 3 can be used. Any AEAD identifier from [I-D.ietf-hpke-hpke] may be used; the resulting context supports Seal(), Open(), and Export(). Key generation follows GenerateKeyPair() from [I-D.ietf-hpke-hpke]. mode_auth_psk may be used via its setup function: the sender calls SetupAuthPSKS() and the receiver calls SetupAuthPSKR(), with a pre- shared key psk and a PSK identifier psk_id, as defined in Section 3.5. As in [RFC9180], both parties are assumped to have been provisioned with the PSK value psk and another byte string psk_id. This mode SHOULD be used with a quantum-resistant PSK value as described below in order to offer hybrid PQ/T confidentiality properties. 3.7.1. PQ/T Hybrid Construction Berra, et al. Expires 16 November 2026 [Page 6] Internet-Draft HPKE Authenticated Modes May 2026 def HybridSetupS(pkR, skS, info, psk, psk_id): enc_dh, ctx = SetupAuthPSKS(pkR, info, psk, psk_id, skS) return enc_dh, ctx def HybridSetupR(enc, skR, pkS, info, psk, psk): return SetupAuthPSKR(enc_dh, skR, info, psk, psk_id, pkS) The suite_id in the HPKE key schedule reflects only the ciphersuite (KEM_ID, KDF_ID, AEAD_ID), where KEM_ID is a DHAKEM. Generation and distribution of a quantum-safe PSK value is left to the application. *Hybrid confidentiality.* KeyScheduleS()/KeyScheduleR() delegate to CombineSecrets, for which [I-D.ietf-hpke-hpke] defines two variants. In CombineSecrets_TwoStage(), the combination is secret = LabeledExtract(dhkem_shared_secret, "secret", psk), equivalent to HKDF-Extract(salt = dhkem_shared_secret, IKM = psk) [RFC5869]. In CombineSecrets_OneStage(), dhkem_shared_secret and psk are length- prefixed and concatenated before a single LabeledDerive() call. In both cases, dhkem_shared_secret and psk enter the combination as independent inputs. The intended design property is that secret remains pseudorandom as long as at least one of the two inputs is--- meaning an adversary would need to attack both the classical DH-based component and the PQ-KEM to recover secret, as seen in [I-D.ounsworth-cfrg-kem-combiners] and subsequently, [I-D.draft-connolly-cfrg-xwing-kem-10]. Whether this property holds formally for a specific CombineSecrets variant depends on that variant's security analysis, which is outside the scope of this document. *Authentication.* This mode retains the implicit sender authentication properties of DHAKEM described in [RFC9180]. A quantum adversary with access to the PSK can also forge authenticated messages. *PSK freshness.* The PSK psk MUST satisfy the entropy requirement in Section 9.5 of [I-D.ietf-hpke-hpke] (32 bytes of uniform randomness). 3.7.2. AKEM/PQ KEM "Combiner" (Informative) Using mode_auth_psk with the shared secret from a PQ-KEM as the provided "psk" value allows application developers to provide hybrid PQ/T security properties using ready-made libraries and APIs. Although this psk value is not a true pre-shared key, this document adopts the pskAPKE terminology from [Alwen2023]. Berra, et al. Expires 16 November 2026 [Page 7] Internet-Draft HPKE Authenticated Modes May 2026 The result is a KEM combiner-style construction [I-D.ounsworth-cfrg-kem-combiners] that provides hybrid PQ/T confidentiality and classical authentication, without requiring developers to manage their own encryption context---a frequent source of developer error and a motivating factor for the API design choices of [RFC9180]. In addition to the keypair specified in Section 3.5, the receiver holds an additional post-quantum keypair, (skR_pq, pkR_pq). Prior to setting up an HPKE encryption context (either via Setup or via a single-shot API), the sender uses receiver's PQ public key pkR_pq to generate a shared secret and its encapsulation (ss_pq, enc_pq), and uses ss_pq as the psk and a static identifier as the PSK identifier. The ciphertext encapsulation of ss_pq, enc_pq, is included in info to bind it to the key schedule. An example construction is provided below, with reference to the following terms: * PQKEM: a post-quantum KEM, e.g., ML-KEM [FIPS203] or an algorithm from [I-D.ietf-hpke-pq]. * PQKEM.Encap(pkR_pq): PQ-KEM encapsulation; returns (enc_pq, ss_pq). * PQKEM.Decap(enc_pq, skR_pq): PQ-KEM decapsulation; returns ss_pq. * Nenc_pq: the fixed ciphertext length of the chosen PQ-KEM, in bytes. def HybridSetupS(pkR, pkR_pq, skS, info): enc_pq, ss_pq = PQKEM.Encap(pkR_pq) enc_dh, ctx = SetupAuthPSKS(pkR, concat(info, enc_pq), ss_pq, enc_pq, skS) return concat(enc_dh, enc_pq), ctx def HybridSetupR(enc, skR, skR_pq, pkR_pq, pkS, info): enc_dh, enc_pq = enc[:Nenc], enc[Nenc:] ss_pq = PQKEM.Decap(enc_pq, skR_pq) return SetupAuthPSKR(enc_dh, skR, concat(info, enc_pq), ss_pq, enc_pq, pkS) *Classical (implicit) sender authentication:* This construction provides only classical sender authentication is provided. In contrast to Section 3.7.1, this "psk" value provides no sender authentication, as it is constructed rather than pre-shared. This limitation is assessed in Section 3.8. Berra, et al. Expires 16 November 2026 [Page 8] Internet-Draft HPKE Authenticated Modes May 2026 The info parameter will exceed 64 bytes. Implementors must ensure their choice of algorithms and underlying implementation can support parameters of this length. The shared secret ss_pq must satisfy the entropy requirement in Section 9.5 of [I-D.ietf-hpke-hpke]. Implementations should verify len(enc) == Nenc + Nenc_pq and reject encapsulations of any other length. A fresh (ss_pq, enc_pq) pair should be generated for each encapsulation; reuse of a prior enc_pq is prohibited. The suite_id in the HPKE key schedule reflects only the ciphersuite (AKEM_ID, KDF_ID, AEAD_ID); the PQ-KEM algorithm identity should be conveyed via application-layer framing when multiple PQ-KEM algorithms are supported. Note that [Alwen2023] describes a related hybrid construction in which a PQ _AKEM_ (rather than an unauthenticated KEM) is used to generate the PSK, which would additionally provide post-quantum sender authentication; that stronger construction is outside the scope of this document. 3.8. Motivation (Informative) Application developers are in a bind: though they may be aware of advice to implement quantum-resistant encryption on an accelerated timeline, they may encounter rapidly-evolving guidance on best practices, a lack of direct parity with classical constructions, and a relative paucity of stable libraries and APIs [PQCodePkgs]. Developers looking to offer hybrid PQ/T encryption in their own applications, for reasons described for example in Section 2.1 of [RFC9370], can look to early-stage implementations of [I-D.draft-connolly-cfrg-xwing-kem-10], or may refer to the now- expired [I-D.ounsworth-cfrg-kem-combiners], but will need to manage their own combiner implementation. On the other hand, production-ready quantum-resistant authentication is still maturing. Standardized schemes offer non-repudiable, signature-based authentication, which is not a direct replacement for the type of DH-based implicit authentication described in the authenticated modes of [RFC9180] or this document. Although the strategy of hybrid encryption with classical authentication is not as straightforward to communicate as unauthenticated hybrid encryption that forgoes implict authentication entirely, protocols such as Noise IK, as used in [Wireguard2020], indicate that this strategy has real-world uses until quantum- resistant authentication methods become more available. Berra, et al. Expires 16 November 2026 [Page 9] Internet-Draft HPKE Authenticated Modes May 2026 Allowing application developers to deploy quantum-resistant encryption as a transitional measure without deprecating the classical authentication properties of their application provides a path towards quantum readiness, similar in concept to Section 3 of [RFC8773] and Section 5.1 of [RFC9257], which also discuss the introduction of quantum-resistent PSK as a transitional measure. 4. Security Considerations The sender-authentication and key-compromise impersonation (KCI) properties of mode_auth_psk are as described in Sections 9.1 and 9.1.1 of [RFC9180], which apply without change to the functions defined in Section 3. Security properties specific to the hybrid PQ/ T construction are discussed informatively in Section 3.7.1. The formal security of the DHKEM authenticated modes under the Gap-DH assumption is established in [Alwen2021]. The security of mode_auth_psk---termed AuthPSK in [Alwen2023]---is analyzed there as the pskAPKE scheme. 5. IANA Considerations This document requests no IANA actions; all identifiers are drawn from registries defined in [I-D.ietf-hpke-hpke]. 6. References 6.1. Normative References [I-D.ietf-hpke-hpke] Barnes, R., Bhargavan, K., Lipp, B., and C. A. Wood, "Hybrid Public Key Encryption", Work in Progress, Internet-Draft, draft-ietf-hpke-hpke-03, 2 March 2026, . [I-D.ounsworth-cfrg-kem-combiners] Ounsworth, M., Wussler, A., and S. Kousidis, "Combiner function for hybrid key encapsulation mechanisms (Hybrid KEMs)", Work in Progress, Internet-Draft, draft-ounsworth- cfrg-kem-combiners-05, 31 January 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Berra, et al. Expires 16 November 2026 [Page 10] Internet-Draft HPKE Authenticated Modes May 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 6.2. Informative References [Alwen2021] Alwen, J., Blanchet, B., Hauck, E., Kiltz, E., Lipp, B., and D. Riepel, "HPKE: Hybrid Public Key Encryption", Advances in Cryptology -- EUROCRYPT 2021, LNCS 12696, pp. 396-427, DOI 10.1007/978-3-030-77886-6_14, 2021, . [Alwen2023] Alwen, J., Janneck, J., Kiltz, E., and B. Lipp, "The Pre- Shared Key Modes of HPKE", Advances in Cryptology -- ASIACRYPT 2023, 2023, . [FIPS203] National Institute of Standards and Technology, "Module- Lattice-Based Key-Encapsulation Mechanism Standard", FIPS 203, August 2024, . [I-D.draft-connolly-cfrg-xwing-kem-10] Connolly, D., Schwabe, P., and B. Westerbaan, "X-Wing: general-purpose hybrid post-quantum KEM", Work in Progress, Internet-Draft, draft-connolly-cfrg-xwing-kem- 10, 2 March 2026, . [I-D.draft-ietf-tls-hybrid-design-16] Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key exchange in TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-hybrid-design-16, 7 September 2025, . [I-D.ietf-hpke-pq] Barnes, R. and D. Connolly, "Post-Quantum and Post- Quantum/Traditional Hybrid Algorithms for HPKE", Work in Progress, Internet-Draft, draft-ietf-hpke-pq-04, 2 March 2026, . [PQCodePkgs] Post Quantum Cryptography Alliance, "PQ Code Package Repositories (accessed 2026-04-30)", 2026, . Berra, et al. Expires 16 November 2026 [Page 11] Internet-Draft HPKE Authenticated Modes May 2026 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC8773] Housley, R., "TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key", RFC 8773, DOI 10.17487/RFC8773, March 2020, . [RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, February 2022, . [RFC9257] Housley, R., Hoyland, J., Sethi, M., and C. A. Wood, "Guidance for External Pre-Shared Key (PSK) Usage in TLS", RFC 9257, DOI 10.17487/RFC9257, July 2022, . [RFC9370] Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, May 2023, . [RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for Post-Quantum Traditional Hybrid Schemes", RFC 9794, DOI 10.17487/RFC9794, June 2025, . [Wireguard2020] Donenfeld, J. A., "WireGuard: Next Generation Kernel Network Tunnel", 2020, . Acknowledgments _TK_ Authors' Addresses Giulio Berra (editor) Freedom of the Press Foundation Email: giulio@freedom.press Cory Francis Myers (editor) Freedom of the Press Foundation Berra, et al. Expires 16 November 2026 [Page 12] Internet-Draft HPKE Authenticated Modes May 2026 Email: cfm@acm.org Rowen Shane (editor) Freedom of the Press Foundation Email: ro@freedom.press Berra, et al. Expires 16 November 2026 [Page 13]